System and methods for prioritizing and processing updated inventory information for event listings

ABSTRACT

System and methods for prioritizing and processing updated inventory information for event listings are described. In one embodiment, a network-based system may receive updated ticket information from a seller for multiple event listings, categorized the updated ticket information from the seller by event, prioritize event categorizing comprising updated ticket information in accordance with a prioritization policy, and process a prioritized event category comprising updated ticket information for a particular event listing out-of-order with respect to one or more other event categories comprising previously received updated ticket information for other event listings. Other embodiments are described and claimed.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.12/346,981 filed Dec. 31, 2008, which is incorporated herein byreference in its entirety.

BACKGROUND

Computer systems and networks have facilitated the tasks of buying,selling and transferring goods. For example, global computer networks,such as the Internet, have allowed purchasers to relatively quickly andefficiently seek and purchase goods online. Similarly, global computernetworks provide an efficient and cost-effective medium for sellers toadvertise, offer, provide, and sell their goods. Electronic commercecompanies provide buyers and sellers with online services and theinfrastructure to accept orders of goods from remote purchasers, toperform the financial transactions necessary to confirm and complete thesale of goods, to ship or distribute the goods to remote purchasers, andto perform other related logistics. For these reasons, sellers activelyuse the Internet to offer, sell and distribute a wide variety of goodsto take advantage of the many benefits provided by the Internet andelectronic commerce.

One example of a market for goods within the realm of electroniccommerce is the secondary ticket market. The secondary ticket marketencompasses all instances in which live event tickets trade after theoriginal point of purchase. This market exists for several reasons.First, event tickets have an especially time-sensitive nature. Numeroustickets expire unused each year because there is no efficient mechanismto buy and/or sell secondary event tickets. When a ticket expires afteran event has passed, it loses all of its intrinsic value. As a result,if the ticket holder cannot attend the event, the only way to realizevalue for a ticket is to sell it in the secondary market. For example,many venues, universities and/or sports franchises offer “seasontickets” which are often packaged in bulk requiring a buyer to purchaseseveral tickets at once. As a result, season ticket holders oftenpossess a number of tickets for events that they cannot attend, andtherefore desire to sell on the secondary market.

Additionally, event venues have only a fixed supply of seating.Therefore, the number of available tickets for a particular event islimited, which means that high-demand events can have significantvolumes of secondary trading. Buyers, who would like to sit only incertain seat locations, further create a supply and demand imbalance.Particularly, each seat location in a venue is totally unique, whichmeans there could be demand for a specific seat location that exceedssupply even when the venue is not sold out in the primary market,thereby favoring the secondary market. Moreover, while tickets forcertain events (e.g., football games of a team in the same venue) may besimilarly priced, the actual supply and demand for such events may besubstantially different, thereby favoring the secondary market.

StubHub provides a network-based system which implements an onlinesecondary ticket marketplace for buyers and sellers of tickets for liveevents such as sports, concerts, theater, and other entertainmentevents. The StubHub online secondary ticket marketplace enableslegitimate, convenient, reliable, and secure transactions at fair marketvalue and provides ticket fulfillment services, even for “sold out”events. Accordingly, the StubHub online secondary ticket marketplaceprovides benefits for fans who wish to buy, sell or otherwise transfersecondary tickets as well as for teams, artists, and venues.

SUMMARY

Various embodiments relate to a system and methods for prioritizing andprocessing updated inventory information for event listings. In oneembodiment, a network-based system may receive updated ticketinformation from a seller for multiple event listings, categorize theupdated ticket information from the seller by event, prioritize eventcategories comprising updated ticket information in accordance with aprioritization policy, and process a prioritized event categorycomprising updated ticket information for a particular event listingout-of-order with respect to one or more other event categoriescomprising previously-received updated ticket information for otherevent listings. Other embodiments are described and claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of variousembodiments will become more readily appreciated and better understoodby reference to the following detailed description and the accompanyingdrawings.

FIG. 1 illustrates an exemplary communications system including anetwork-based system for providing online marketplace and ticketfulfillment services in accordance with various embodiments.

FIG. 2 illustrates a listing manager system for prioritizing andprocessing updated inventory information for event listings inaccordance with various embodiments.

FIG. 3 illustrates a logic flow including operations performed by acomputer for prioritizing and processing updated inventory informationfor event listings in accordance with various embodiments.

DETAILED DESCRIPTION

Various embodiments are described for prioritizing and processingupdated inventory information for event listings provided by an onlineticket marketplace implemented by a network-based system. Numerousspecific details are set forth to provide a thorough understanding ofthe embodiments. It will be understood by those skilled in the art,however, that the embodiments may be practiced without these specificdetails. In other instances, well-known operations, components andcircuits have not been described in detail so as not to obscure theembodiments. It can be appreciated that the specific structural andfunctional details disclosed herein may be representative and do notnecessarily limit the scope of the embodiments.

Reference throughout the specification to “various embodiments,” “someembodiments,” “one embodiment,” or “an embodiment” means that aparticular feature, structure, or characteristic described in connectionwith the embodiment is included in at least one embodiment. Thus,appearances of the phrases “in various embodiments,” “in someembodiments,” “in one embodiment,” or “in an embodiment” in placesthroughout the specification are not necessarily all referring to thesame embodiment. Furthermore, the particular features, structures orcharacteristics may be combined in any suitable manner in one or moreembodiments.

FIG. 1 illustrates a communications system 100 suitable for implementingvarious embodiments. The elements of the communications system 100generally may comprise physical or logical entities for communicatinginformation and, in some cases, may be implemented as hardware,software, or combination thereof, as desired for a given set of designparameters or performance constraints. Although FIG. 1 includes alimited number of elements for purposes of illustration, it can beappreciated that the communications system 100 may include more or lesselements as well as other types of elements.

Various elements of the communications system 100 may be implementedutilizing one or more computing devices having computing and/orcommunications capabilities in accordance with the describedembodiments. Exemplary computing devices may include, withoutlimitation, a mobile device, a personal digital assistant (PDA), amobile computing device, a communications device, a telephone, a mobiletelephone, a cellular telephone, a smart phone, a handset, a one-waypager, a two-way pager, a messaging device, a computer, a personalcomputer (PC), a desktop computer, a work station, a laptop computer, anotebook computer, a tablet computer, a handheld computer, amini-computer, a network appliance, a web appliance, a server, a servercomputer, a server array, a server farm, an Internet server, a webserver, a network server, a main frame computer, a supercomputer, adistributed computing system, multiprocessor system, processor-basedsystems, a control system, consumer electronic equipment, a mediadevice, a gaming device, a television, a digital television, a set-topbox (STB), wireless access point, base station, subscriber station,mobile subscriber center, radio network controller, a network accessdevice, a telephone network device, a mobile telephone network device, aVoIP network device, a radio network device, a television networkdevice, a satellite network device, a router, a hub, a gateway, abridge, a switch, a machine, or combination thereof.

The computing devices utilized by the communications system 100 may beimplemented by various hardware and/or software components in accordancewith the described embodiments. Exemplary hardware components mayinclude processing devices such as central processing unit (CPU) and/orother processors, microprocessors, application processors, radioprocessors, baseband processors, digital signal processors (DSP),circuits, circuit elements (e.g., transistors, resistors, capacitors,inductors, and so forth), integrated circuits, application specificintegrated circuits (ASIC), programmable logic devices (PLD), a fieldprogrammable gate array (FPGA), logic gates, registers, semiconductordevice, chips, microchips, chip sets, memory such as volatile and/ornon-volatile memory, a display such as a liquid crystal display (LCD) orcathode ray tube (CRT), input devices such a keyboard, mouse, stylus,touch pad, and/or touch screen, networking devices such as ports,network interface cards (NICs), transmitters, receivers, transceivers,and/or antennas, as well as other components. Exemplary softwarecomponents may include computer programs, applications, applicationprograms, system programs, operating system (OS) software, middleware,firmware, a software interface, a programmatic interface, an applicationprogram interfaces (API), a network interface, a web interface, amessaging interface, modules, instruction sets, routines, subroutines,functions, calls, computing code, or combination thereof.

Various elements of the communications system 100 may support wiredand/or wireless communications functionality in accordance with thedescribed embodiments. For example, some computing devices may bearranged to communicate information over one or more types ofcommunication links such as a wire, cable, bus, printed circuit board(PCB), backplane, switch fabric, semiconductor material, twisted-pairwire, co-axial cable, fiber optic connection, Ethernet connection,peer-to-peer (P2P) connection, a data channel, a radio channel, asatellite channel, a television channel, a broadcast channel, aninfrared (IR) channel, a radio-frequency (RF) channel, a portion of theRF spectrum, one or more licensed or license-free frequency bands, andso forth.

Various elements of the communications system 100 may supportcommunication over one or more types of networks in accordance with thedescribed embodiments. For example, some computing devices and networksmay support communications over a Wide Area Network (WAN), the Internet,a telephone network (e.g., analog, digital, POTS, PSTN, ISDN, xDSL), amobile telephone network (e.g., CDMA, GSM, NDAC, TDMA, E-TDMA, NAMPS,WCDMA, CDMA-2000, UMTS, 3G, 4G), a radio network, a television network,a cable network, an optical network (e.g., PON), a satellite network(e.g., VSAT), a packet-switched network, a circuit-switched network, apublic network, a private network, and/or other wired or wirelesscommunications network configured to carry data. Computing devices andnetworks also may support wireless wide area network (WWAN)communications services including Internet access such as EV-DO, EV-DV,CDMA/1xRTT, GSM/GPRS, EDGE, HSDPA, HSUPA, and others.

Computing devices and networks may support wireless local area network(WLAN) and/or wireless metropolitan are network (WMAN) datacommunications functionality in accordance with Institute of Electricaland Electronics Engineers (IEEE) standards, protocols, and variants suchas IEEE 802.11 (“WiFi”), IEEE 802.16 (“WiMAX”), IEEE 802.20x(“Mobile-Fi”), and others. Computing devices and networks also maysupport short range communication such as a wireless personal areanetwork (WPAN) communication, Bluetooth® data communication, infrared(IR) communication, near-field communication, electromagnetic induction(EMI) communication, passive or active RFID communication, micro-impulseradar (MIR), ultra-wide band (UWB) communication, automaticidentification and data capture (AIDC) communication, and others.

Further aspects and advantages of various embodiments will become morereadily appreciated and better understood by the following descriptionof the elements of the communications system 100 illustrated in FIG. 1.Although certain exemplary embodiments and implementations may beillustrated and described as comprising a particular combination ofelements and performing a particular set of operations, it is to beunderstood that the principles and techniques discussed herein are notlimited to such examples.

In the embodiment shown in FIG. 1, the communications system 100includes, among other elements, a client 102 which may comprise oremploy one or more client devices 104 such as a mobile computing device,a PC, and/or any other computing device having computing and/orcommunications capabilities in accordance with the describedembodiments. The client devices 104 generally may provide one or moreclient programs 106 such as system programs and application programs toperform various computing and/or communications operations. Exemplarysystem programs may include, without limitation, an operating system(e.g., MICROSOFT® OS, UNIX® OS, LINUX® OS, Symbian OS™, Embedix OS,Binary Run-time Environment for Wireless (BREW) OS, JavaOS, a WirelessApplication Protocol (WAP) OS, and others), device drivers, programmingtools, utility programs, software libraries, application programminginterfaces (APIs), and so forth. Exemplary application programs mayinclude, without limitation, a web browser application, messagingapplications (e.g., e-mail, IM, SMS, MMS, telephone, voicemail, VoIP,video messaging), contacts application, calendar application, electronicdocument application, database application, media application (e.g.,music, video, television), location-based services (LBS) application(e.g., GPS, mapping, directions, point-of-interest, locator), and soforth. In some usage scenarios, one or more of the client programs 106may display various graphical user interfaces (GUIs) to presentinformation to and/or receive information from one or more of the clientdevices 104.

As shown, the client 102 is communicatively coupled via one or morenetworks 108 to a network-based system 110. The network-based system 110may be structured, arranged, and/or configured to allow the client 102to establish one or more communications sessions with the network-basedsystem 110 using various computing devices 104 and/or client programs106. Accordingly, a communications session between the client 102 andthe network-based system 110 may involve the unidirectional and/orbidirectional exchange of information and may occur over one or moretypes of networks 108 depending on the mode of communication. While theembodiment of FIG. 1 illustrates the communications system 100 deployedin a client-server operating environment, it is to be understood thatother suitable operating environments and/or architectures may be usedin accordance with the described embodiments.

Data and/or voice communications between the client 102 and thenetwork-based system 110 may be sent and received over one or morenetworks 108 such as the Internet, a WAN, a WWAN, a WLAN, a mobiletelephone network, a landline telephone network, a VoIP network, as wellas other suitable networks. For example, the client 102 may communicatewith the network-based system 110 over the Internet or other suitableWAN by sending and or receiving information via interaction with a website, e-mail, IM session, and/or video messaging session. The client 102also may communicate with the network-based system 110 via a telephonecall to a customer service agent and/or interactive voice response (IVR)system made over a mobile telephone network, a landline network, and/ora VoIP network. In wireless implementations, the client 102 maycommunicate with the network-based system 110 over the Internet via aWLAN or mobile telephone network that supports WWAN communicationsservices. The client 102 also may communicate over a mobile telephonenetwork via SMS and/or MMS messaging. It is to be appreciated that theembodiments are not limited in this regard.

In various usage scenarios, communication sessions and/or messagingbetween the client 102 and the network-based system 110 may involvemultiple modes of communication and/or multiple networks. In some cases,for example, the client 102 may initiate communication with thenetwork-based system 110 by interacting with a web site. In response,the network-based system 110 may communicate with the client 102 in avariety of ways such as via the web site, e-mail, IM, SMS, MMS, and/or atelephone call from a customer service agent and/or IVR system. Thecommunication from the network-based system 110 may comprise a message(e.g., e-mail, IM, SMS, MMS) containing relevant static or dynamiccontent, an embedded hyperlinked URL for directing the client 102 to aweb site, and/or a hyperlinked telephone number for allowing the client102 to click and place a telephone call to an agent (e.g., customerservice agent and/or IVR system) of the network-based system 110.

When communicating with the network-based system 110, the client 102 mayemploy one or more client devices 104 and/or client programs 106. Invarious implementations, the client devices 104 and/or client programs106 may host or provide one or more interfaces for communicating withthe network-based system 110. Exemplary interfaces may include a webinterface, an API interface, a messaging interface, and/or othersuitable communication interface in accordance with the describedembodiments. The client programs 106 for communicating with thenetwork-based system 110 may comprise, for example, pre-installed,authored, downloaded, and/or web-based computer programs.

The client programs 106 provided by one or more of the client devices104 (e.g., mobile computing device and/or PC) may include a web client.The web client may comprise, for example, a desktop and/or mobile (e.g.,WAP) web browser (e.g., Internet Explorer®, Mozilla®, Firefox®, Safari®,Opera®, Netscape Navigator®, etc.) capable of rendering web pages (e.g.,HTML documents) and supporting various browser-based web technologiesand programming languages such as HTML, XHTML, CSS, Document ObjectModel (DOM), XML, XSLT, XMLHttpRequestObject, JavaScript, ECMAScript,Jscript, Ajax, Flash®, Silverlight™, Visual Basic® (VB), VB ScriptingEdition (VBScript), PHP, ASP, Java®, Shockwave®, Python, Perl®, C#/.net,and/or others.

In various usage scenarios, the client 102 may use a web client toprovide an interface (e.g., HTTP interface) for navigating to a web siteassociated with the network-based system 110 and for requesting andreceiving web page data from the network-based system 110. For example,the client 102 may use the web client to navigate to a web siteassociated with the network-based system 110 by entering a URL into aweb browser address bar and/or by clicking on a hyperlinked URLdelivered to the client 102 via a web page, web-based application,e-mail, IM, SMS, MMS, and/or other delivery mechanism.

In one or more embodiments, the web client may comprise or beimplemented as a web browser toolbar for communicating with thenetwork-based system 110. In such embodiments, the web browser toolbarmay include, for example, a button (e.g., dedicated, customized, add-on)and/or a hyperlinked URL for navigating to a web site associated withthe network-based system 110. The web browser toolbar also may implementenhanced features such as a search engine interface (e.g., text entrybox, input fields, checkboxes, clickable hyperlinks) and/or one or morepull-down menus for accessing the network-based system 110, sendinginformation (e.g., search query, keywords, user preferences, menuselections) to the network-based system 110, and/or receivinginformation (e.g., search results, relevant static or dynamic content)from the network-based system 110.

In one or more embodiments, the web client may comprise or beimplemented as a widget such as a desktop or mobile widget forcommunicating with the network-based system 110. In such embodiments,the desktop or mobile widget may comprise web-based code, aninterpreter, a virtual machine, and/or an API implementation to request,receive, present, and/or update content hosted by the network-basedsystem 110. The desktop or mobile widget may comprise, for example, aclient-side web application displayed on the desktop or phone-top of oneor more of the client devices 104 implemented using various webtechnologies and programming languages. In various implementations, thedesktop or mobile widget may be supported by a host runtime environmentsuch as a web browser or suitable rendering engine and/or may beinstalled and run as a stand-alone application outside of a web browser.

In various embodiments, the network-based system 110 may provide userswith one or more client-side web applications as described in co-pendingU.S. patent application Ser. No. 12/275,783 titled “System and Methodsfor Providing Location-Based Upcoming Event Information Using aClient-Side Web Application Implemented on a Client Device,” which wasfiled on Nov. 21, 2008 and is incorporated by reference in its entirety.In such embodiments, once downloaded and installed on a client device(e.g., PC or mobile device) of the user, the client-side web applicationmay be configured to provide upcoming event information based upon thelocation of the user.

The client programs 106 executed by one or more of the client devices104 may include a programmatic client for accessing and communicatingwith the network-based system 110. Along with performing a certain setof functions, the programmatic client may include, for example, animplementation of an API provided by the network-based system 110 forenabling access to and/or communication with various elements (e.g.,servers, databases) of the network-based system 110. In variousembodiments, the API implementation may comprise executable code inaccordance with an SDK provided by the network-based system 110.

The client programs 106 executed by one or more of the client devices104 (e.g., mobile computing device and/or PC) also may include amessaging client. The messaging client may comprise, for example, anapplication that supports one or more modes of communication such ase-mail, IM, SMS, MMS, telephone, VoIP, video messaging, and so forth. Itcan be appreciated that some messaging clients may require and/or launchan Internet connection in the background when executed.

In various embodiments, the communications system 100 includes, amongother elements, one or more other online marketplace systems 112. Theother online marketplace systems 112 may communicate with and enable thenetwork-based system 110 to provide the client 102 with additionalservices and/or information such as additional ticket inventory. Invarious embodiments, access to the network-based system 110 may providethe user with the ability to receive aggregated content and/or onlinemarketplace and ticket fulfillment services of the network-based system110 and one or more other online marketplace systems 112 (eBay®services, Kijiji™ services, PayPal™ services, etc.). For example, thelocation-based upcoming event information may include event listingspublished by sellers via the online marketplace services of thenetwork-based system 110 as well as event listings published by sellersvia one or more of the other online marketplace systems 118 (e.g., eBay®online marketplace, Kijiji™ online marketplace).

As shown in FIG. 1, the communications system 100 includes a third party114 which, in turn, may comprise or employ a third-party server 116hosting a third-party application 118. While FIG. 1 shows only the thirdparty 114 for purposes of illustration, it can be appreciated that thecommunication system 100 may comprise multiple different third-parties.The third-party server 116 and/or third-party application 118 may host athird-party web site associated with or employed by a third party 114such as an affiliate, partner, or other third-party entity or user inaccordance with the described embodiments. In some usage scenarios, oneor more of the client programs 106 may be used to access thenetwork-based system 110 after initially communicating with athird-party web site. For example, the web site of the third party 114(e.g., affiliate, partner) may comprise a hyperlinked advertisementthat, when clicked, directs to the web client to a web page hosted bynetwork-based system 110. In some cases, the third party 114 may bedirectly or indirectly compensated for directing traffic from thethird-party web site to the web site of the network-based system 110and/or in the event that an electronic commerce transaction resultsafter a user is directed from the third-party web sites to the web siteof the network-based system 110.

In various embodiments, the network-based system 110 may provide onlinemarketplace and ticket fulfillment services for sellers of tickets forlive events such as sports, concerts, theater, and other entertainmentevents. In one or more of such embodiments, the third-party application118 hosted by the third party 114 may promote, enhance, complement,supplement, and/or substitute for one more services provided by thenetwork-based system 110. For example, the third party 114 may provide aserver-side web application such as a web widget and/or an APIimplementation for accessing the network-based system 110 via thethird-party application 118, a third-party web site, and/or athird-party web page as described in co-pending U.S. patent applicationSer. No. 12/338,158 titled “System and Methods for Third-Party Access toa Network-Based System for Providing Location-Based Upcoming EventInformation,” which was filed on Dec. 18, 2008 and is incorporated byreference in its entirety.

When implemented by a client 102 and/or a third party 114, webapplications may access and receive content and/or online services fromthe network-based system 110 and/or other online marketplace systems112. The web applications may be implemented using various webtechnologies and programming languages (e.g., interpreted, compiled,scripting, virtual machine, etc.) and/or in accordance with a softwaredevelopment kit (SDK). For example, a web application may compriseweb-based code configured for communication with the network-basedsystem 110 and/or other online marketplace systems 112. In someimplementations, the web application may be configured to present anaggregate of ticket inventory available from multiple onlinemarketplaces including the network-based system 110 and one or moreother online marketplace systems 112 and to provide the user withmultiple purchasing options.

In various embodiments, the network-based system 110 may communicatewith and provide online services to users such as buyers and sellers ofgoods. It is to be appreciated that goods for purchase and/or sale mayinclude both tangible goods (e.g., physical tickets, electronictickets), intangible goods (e.g., rights and/or licenses that areafforded by the tickets), and other goods in accordance with thedescribed embodiments. It also is to be appreciated that users otherthan buyers and/or sellers may communicate with the network-based system110. In some cases, for example, the client 102 may be associated withan administrator or customer service agent and may communicate with thenetwork-based system 110 to monitor, update, and/or otherwise manage oneor more computing devices and/or services of the network-based system110.

In accordance with various embodiments, the network-based system 110 maycommunicate with a point-of-sale (POS) and/or inventory managementsystem configured to manage inventory and/or communicate with thenetwork-based system 110. The POS and/or inventory management system maybe implemented, for example, by a client 102, other marketplace systems112, third party 114, and/or other user. The POS and/or inventorymanagement system may be implemented by one or more computer systemscomprising computing devices such as PCs, servers, and/or other suitabledevices and computer programs such as a stand-alone or web-based POSand/or inventory management application for managing a large volume ofavailable inventory and communicating with the network-based system 110.

In some usage scenarios, the POS and/or inventory management system maybe employed by a high-volume seller such as a ticket broker to author,update, and manage a large number of inventory listings. In other usagescenarios, the POS and/or inventory management may be employed by anagent of the network-based system 110 at a drop-off location that mayhandle the responsibility of accepting tickets from sellers, shippingthe tickets to the buyer, delivering the tickets to the event venue willcall, and/or the keeping the tickets until pick-up by the buyer. It canbe appreciated that as tickets are sold, the actual available inventoryassociated with ticket listings may be extremely dynamic especially incases where a seller (e.g., ticket broker) may sell inventory publishedby the network-based system 110 independently of the network-basedsystem 110. For example, a ticket broker may sell tickets directly tocustomers and also may use the network-based system 110 as one ofseveral other channels to sell tickets.

The POS and/or inventory management system may be configured to performbatch-mode communication with the network-based system 110 to provideupdated inventory information for event listings. The batch-modecommunication from may comprise inventory data for numerous inventoryitems (e.g., hundreds, thousands) for publication by the network-basedsystem 110. Accordingly, such batch-mode communication allowshigh-volume sellers to update inventory to be published by thenetwork-based system 110 without having to individually enter items forsale on a ticket-by-ticket basis.

In some usage scenarios, a batch of inventory information communicatedfrom a ticket broker to the network-based system 110 may comprise a fullfile job listing of all inventory of the ticket broker at a particularpoint in time. In other usage scenarios, a batch of inventoryinformation communicated from a ticket broker to the network-basedsystem 110 may comprise a delta job listing changes to inventoryinformation previously sent or uploaded by the ticket broker to thenetwork-based system 110. In some cases, a batch of inventorycommunicated by a ticket broker may comprise a consolidation of listingsfrom multiple ticket brokers. The consolidation of listings(consolidator job), in turn, may include full file jobs and/or deltajobs for multiple ticket brokers.

In some implementations, the network-based system 110 may communicatewith and receive updated inventory information for ticket listings fromone or more POS and/or inventory management systems in real time. Insuch implementations, the POS and/or inventory management system may beconfigured to provide real-time inventory updates so that the eventlistings published by network-based system 110 are synchronized with andaccurately reflect the available inventory for sale of a high-volumeseller (e.g., ticket broker).

In other implementations, the network-based system 110 may communicatewith and receive updated inventory information for ticket listings fromone or more POS and/or inventory management systems that may not havereal-time updating functionality. In such implementations, high-volumesellers (e.g., ticket brokers) want updated inventory informationcommunicated to the network-based system 110 to be published as quicklyas possible in order to maximize the opportunity for selling especiallyduring critical time periods associated with an event. For example, thedays including and/or immediately following the on-sale date for ticketsto an event are time periods of high activity for buying and selling.The days immediately preceding and/or including the event date also aretime periods of high activity for buying and selling. The time periodbetween such high-activity time period generally is a time of loweractivity for ticket sales and, in some cases, may be considered lesscritical. It can be appreciated that after an event date has passed,tickets for the event will have no value.

In accordance with various embodiments, the network based system 110 maybe configured to prioritize and process updated inventory informationfor event listings. In such embodiments, the network-based system 110may be arranged to receive updated inventory information and to processworkloads comprising updated inventory information efficiently,intelligently, fairly, and accurately to ensure that the listingspublished by the network-based system 110 reflect updated inventoryavailable for sale especially during critical time periods associatedwith an event. Further details of such embodiments are described belowwith reference to FIGS. 2 and 3.

FIG. 1 illustrates an exemplary embodiment of the network-based system110 for providing online ticket marketplace. As shown, the network-basedsystem 110 may comprise or implement a plurality of servers and/orsoftware components that operate to perform various methodologies inaccordance with the described embodiments. Exemplary servers mayinclude, for example, stand-alone and enterprise-class servers operatinga server OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or othersuitable server-based OS. It can be appreciated that the serversillustrated in FIG. 1 may be deployed in other ways and that theoperations performed and/or the services provided by such servers may becombined or separated for a given implementation and may be performed bya greater number or fewer number of servers.

In various implementations, the servers of the network-based system 110may comprise or implement software components deployed in a tieredenvironment, where one or more servers are used to host server softwarerunning in each tier. For example, using a three-tiered architecture,one or more server software components may be hosted by front-endservers, one more server software components may be hosted by a middletier or middleware implemented by application servers, and one moreserver software components may be hosted by a back-end tier implementedby databases and/or file systems. In some embodiments, servers of thenetwork-based system 110 may be communicatively coupled with each othervia a local area network (LAN) and/or suitable intranet or back-endnetwork.

The network-based system 110 may comprise one or more communicationsservers 120 for providing suitable interfaces to enable communicationusing various modes of communication and/or via one or more networks108. In the embodiment of FIG. 1, the communications servers 120 includea web server 122, an API server 124, and a messaging server 126 toprovide interfaces to one or more application servers 130. Theapplication servers 130 of the network-based system 110 may bestructured, arranged, and/or configured to provide various onlinemarketplace and/or ticket fulfillment services to users that access thenetwork-based system 110.

In various usage scenarios, the client 102 may communicate with theapplications servers 130 of the network-based system 110 via one or moreof a web interface provided by the web server 122, a programmaticinterface provided by the API server 124, and a messaging interfaceprovided by the messaging server 126. It can be appreciated that the webserver 122, the API server 124, and the messaging server 126 may bestructured, arranged, and/or configured to communicate with varioustypes of client devices 104 and/or client programs 106 and mayinteroperate with each other in some implementations.

The web server 122 may be arranged to host web pages (e.g., HTMLdocuments) and provide an appropriate web interface (e.g., HTTP, CGI,etc.) for enabling data to be presented to and received from entitiesvia the Internet. The web server 122 may be arranged to communicate withweb clients and/or applications such as a web browser, web browsertoolbar, desktop widget, mobile widget, web-based application, web-basedinterpreter, virtual machine, and so forth. The web server 122 mayprovide a web interface to enable access by the client 102 and/or thethird party 114 to the various services and functions provided by theapplication servers 130. For example, the web server 122 may be arrangedto receive data from the client 102 and/or third party 114 and to passthe data to one or more application servers 130 within the network-basedsystem 110. The web sever 122 also may present the client 102 and/orthird party 114 with relevant static and dynamic content hosted by thenetwork-based system 110 in response to various requests and/or events.

The API server 124 may be arranged to communicate with various clientprograms 106 and/or a third-party application 118 (e.g., third-party website) comprising an implementation of API for the network-based system110. The API server 124 may provide a programmatic interface to enableaccess by the client 102 and/or the third party 114 to the variousservices and functions provided by the application servers 130. Forexample, the programmatic interface provided by the API server 124 maybe used for batch-mode and/or real-time communication with a high-volumeseller for receiving and updating inventory listings. The programmaticinterface provided by the API server 124 also may be used to communicaterelevant static or dynamic content hosted by the network-based system110 to an API implementation of one or more client programs 106 and/or athird-party application 118 (e.g., third-party web site). The APIimplementation may comprise, for example, executable code in accordancewith a SDK provided by the network-based system 110.

The messaging server 126 may be arranged to communicate with variousmessaging clients and/or applications such as e-mail, IM, SMS, MMS,telephone, VoIP, video messaging, and so forth. The messaging server 126may provide a messaging interface to enable access by the client 102and/or the third party 114 to the various services and functionsprovided by the application servers 130. For example, the messaginginterface provided by the messaging server 126 may be used tocommunicate with the client 102 and/or the third party 114 in a varietyof ways such as via e-mail, IM, SMS, MMS, video messaging, and/or atelephone call (e.g., landline, mobile, VoIP) with a customer serviceagent and/or IVR system.

When implemented as an online ticket marketplace, the applicationservers 130 of the network-based system 110 may provide various onlinemarketplace and ticket fulfillment services including, for example,account services, buying services, selling services, listing catalogservices, dynamic content management services, delivery services,payment services, notification services, and other services inaccordance with the described embodiments. In the exemplaryimplementation shown in FIG. 1, the application servers 130 may comprisean account server 132, a selling server 134, a buying server 136, alisting catalog server 138, a dynamic content management server 140, apayment server 142, a notification server 144, and a delivery server 146structured and arranged to provide such online marketplace and ticketfulfillment services.

The application servers 130, in turn, may be coupled to and capable ofaccessing one or more databases 150 including a subscriber database 152,an active events database 154, and a transaction database 156. Thedatabases 150 generally may store and maintain various types ofinformation for use by the application servers 130 and may comprise orbe implemented by various types of computer storage devices (e.g.,servers, memory) and/or database structures (e.g., relational,object-oriented, hierarchical, dimensional, network) in accordance withthe described embodiments.

Account Services

The account server 132 implemented by one or more of the applicationservers 130 may allow a user to establish and/or manage a subscriberaccount with the network-based system 110. For example, while someservices provided by the network-based system 110 may be generallyaccessible, a user may be required to access an existing subscriberaccount or register a new subscriber account with the network-basedsystem 110 in order to receive certain customized and/orsubscriber-specific services.

To create a subscriber account, a user may provide the network-basedsystem 110 with account information such as a unique username, e-mailaddress, password, name, location (e.g., address, city, country, and/orzip code), telephone numbers (e.g., home, work, and/or mobile), and/orother required information for identifying and/or authenticating theuser. After receiving the required account information and instructionsfrom the user to create the subscriber account, the network-based system110 may create the subscriber account and store the account informationin the subscriber database 152.

After a subscriber account is created, the user may view and/or makechanges to account information, add or edit existing contacts, retrieveor change the password, view and edit sources of funds and/or financialvalue on file, view and edit payment options, and/or otherwise managethe subscriber account.

To effectuate the buying or selling of goods such as event tickets, theuser may be required to link the subscriber account of to a source offunds and/or financial value for completing different transactions viathe network-based system 110. It can be appreciated that the user mayprovide various types of entities or third-party financial accountscapable of supplying or receiving funds and/or financial value inaccordance with the described embodiments. Exemplary entities and/orthird-party financial accounts may include, without limitation, a bank,bank account, lender, line-of-credit, credit card company, credit cardaccount, debit card, prepaid debit card account, third-party paymentservices account (e.g., PayPal™ account), payroll account, check, moneyorder, or any other suitable source of financial value.

Additionally or alternatively to linking the subscriber account to asource of financial value based on a commercial currency (e.g., U.S.dollar), a user may link to the subscriber account to a source offinancial value based on a proprietary and/or promotional currency(e.g., points, rewards, coupons) capable of accumulation and/orredemption by the user to pay for goods or services. It can beappreciated that multiple sources of funds and/or financial valueassociated with the user may be linked to the subscriber accountenabling the user to select among such sources to effectuate differentpayment transactions via the network-based system 110.

The user may select various options for receiving payment when a sale iseffectuated via the network-based system 110. For example, the user mayrequest payment for sales via check, deposit to a third-party paymentservices account (e.g., PayPal™ account) or Season Ticket Account,and/or other type of source capable of receiving funds and/or financialvalue in accordance with the described embodiments. In someimplementations, the user may select to donate some or all of theproceeds of a sale to a third-party such as a non-profit organization orentity (e.g., charity, foundation, fund, alliance, society) as describedin co-pending U.S. patent application Ser. No. 10/697,850 titled “Systemand Method for Providing Logistics for a Sale or Transfer of Goods withProceeds Provided to a Third Party,” which was filed on Oct. 30, 2003and is incorporated by reference in its entirety.

When accessing the subscriber account, the user may view and/or managevarious details of past and pending transactions. For example, thesubscriber account may provide a seller with details regarding past andpending ticket sale listings (e.g., shipped, canceled, inactive,expired, deleted, active, pending confirmation, awaiting shipment) andmay allow the user to track event listings, modify the prices of eventlistings, view and confirm received orders, view and confirm orders toship, print or reprint shipping labels, view shipped orders, viewcanceled orders, view the status of payments and edit payment options,view past payments, and so forth.

In accordance with various embodiments, a high-volume seller (e.g.,ticket broker) may be presented with an interface comprising a set ofscreens for viewing uploaded ticket inventory and/or for manipulatinginventory information (e.g., ticket details). In such embodiments, thehigh-volume seller may access and view the subscriber account using aweb browser and/or POS and/or inventory management application. In somecases, the seller may view and/or filter uploaded inventory by genre,event, or other ticket criteria.

The subscriber account also may provide a buyer with details regardingpast and pending ticket purchase transactions (e.g., past orders,purchased, delivered, canceled, expired, order status, delivery status,active bids, auctions lost) and may allow the user to view orderhistory, track active bids, modify offers, download and print electronictickets, view and edit payment options, and so forth.

The user may customize a subscriber account with one or more interestsand ticketing preferences. For example, a user may add and editinformation associated with a subscriber account regarding one or morecities, venues, artists, teams and sporting events, theaters, and seasonticket and packages of interest to the user. In some cases, buyers mayrequest to receive promotions via an e-mail newsletter featuring eventshappening in a particular location.

Users also may customize subscriber accounts with one or morenotification preferences. For example, a user may configure a subscriberaccount to receive notifications, change notifications, and/ordiscontinue notifications. Users may subscribe to receive customizednotifications in a variety of ways such as via e-mail, IM, SMS, MMS,and/or other suitable delivery mechanism. In addition to receiving suchnotifications via e-mail, IM, SMS, MMS, a user may access the subscriberaccount and view recent notifications such as alert notifications andother messages received in the past week.

In accordance with various embodiments, a seller such as a high-volumeseller (e.g., ticket broker) may automatically receive one or morenotifications when updated inventory information communicated to thenetwork-based system 110 is received, published, and/or changed. Forexample, the stages involved in receiving, prioritizing, and processingupdated inventory information may be monitored by the network-basedsystem 110, and notifications may be provided to the subscriber accountand/or a computing device of the seller to confirm receipt andprocessing of the updated inventory information and/or to alert theseller in the event that a failure condition is encountered at anystage.

In various implementations, a subscriber account may be provided and/orassociated with a priority level or grade. For example, thenetwork-based system 110 may provide and/or associate a priority level(e.g., platinum, gold, silver, etc.) with an account according tocriteria such as number of listings, volume of sales, commissiongenerated, comments (e.g., positive or negative feedback), and so forth.In some cases, subscribers may be promoted or demoted to differentpriority levels according to a scheme that attributes points based onactivity. In one or more of such implementations, a subscriber mayalternatively or additionally pay a premium (e.g., fixed fee, additionalcommission percentage) to obtain a particular priority level. Inaccordance with the described embodiments, the priority level or gradeassociated with a high-volume seller (e.g., ticket broker) may be usedby the network-based system 110 for prioritizing and/or processingupdated inventory information for event listings.

Selling Services

The selling server 134 implemented by one or more of the applicationservers 130 may allow a user to offer goods for sale via an onlinemarketplace provided by the network-based system 110. To list goods forsale such as a single or multiple event tickets, a seller may providethe network-based system 110 with required event information such asevent, location of the tickets, sale type, ticket quantity, seatingdetails (e.g., section, row, seat, comments), price, and payment method.After receiving the required event information and instructions from theseller to publish an event listing, the network-based system 110 maycreate an active event and store the event information in the activeevents database 154 for publication to users of the network-based system110. It can be appreciated that upon the sale of the tickets, one ormore delivery options may be available depending on the locations of thebuyer and the seller, the time remaining before the event, and/or theform of the tickets (e.g., physical tickets, electronic tickets).

In various embodiments, a seller may post an event for publication asdescribed in co-pending U.S. patent application Ser. No. 11/689,787titled “System and Method for Posting Multiple Items for Sale,” whichwas filed on Mar. 22, 2007 and is incorporated by reference in itsentirety. In such embodiments, the seller may select the appropriatetype of event, city, or venue for event tickets being offered for sale,and then may be queried or prompted to select a specific event aftermaking selections from various categories and subcategories presentedvia a set of interactive pull-down menus.

In one implementation, for example, a seller may be presented with apull-down menu listing categories such as sports tickets, concerttickets, theater and arts tickets, and ticket gift certificates. If theseller selects the sports tickets category, a pull-down menu listingsports tickets such as baseball tickets, basketball tickets, footballtickets, and other types of sports tickets is presented. If the sellerthen selects football tickets, a pull-down menu listing sportssubcategories such as NFL tickets, CFL tickets, and NCAA tickets ispresented. If the seller selects the NFL tickets, a pull-down menulisting ticket subcategories such as NFL regular season tickets, NFLplayoff tickets, and NFL pro bowl tickets is presented. If the sellerselects the NFL regular season tickets, a pull-down menu listing NFLteams is presented. Once the seller selects tickets for particular NFLteam, a listing of available events including event details (e.g., teamand opponent, date, time, venue name) for the team are displayed whichcan be sorted by event, date, and venue. The seller may then select anevent from the listing of available events. It can be appreciated thatappropriate sets of pull-down menus for listing categories andsuccessive subcategories may be presented for any type of event ticketin accordance with the described embodiments.

After an event has been selected, the seller may provide thenetwork-based system 110 with the shipping location of the tickets andverify current contact information (e.g., address and telephone phonenumber). The seller may provide a sale type such as a fixed price sale(e.g., set price capable of subsequent modification), a declining pricesale (e.g., automatically decreasing price over time from maximum priceto minimum), or an auction sale (e.g., buyers bid from a starting priceduring an open period with the highest bidder placing an order when theauction closes).

The seller may provide the ticket quantity for specific seats or generaladmission. The seller may provide the ticket quantity and may allow thequantity of offered tickets to be split among several buyers inmultiples of two. The seller may provide seating and ticket details forthe offered tickets such as section, row, seat numbers, and may provideother comments. In some cases, the seller may select to prevent buyersfrom viewing the specific seat numbers when the event listing ispublished by the network-based system 110.

The seller may provide the price per ticket and the ending date of thesale when the event listing is to be removed from publication. For someevents, the event listing may expire three business days before theevent. In certain markets, tickets may be sold on consignment and thelisting may remain until the start of the event.

The seller may provide a selected payment method for the sale of thetickets such as via check, deposit to a third-party payment servicesaccount (e.g., PayPal™ account), Season Ticket Account, and/or othertype of source capable of receiving funds and/or financial value, and/ordonation to a third-party such as a non-profit organization or entity.

In various implementations, the seller may support the delivery ofelectronic tickets to a buyer. In such implementations, the seller mayassociate a listing for an event with one or more of a media file (e.g.,PDF file), a uniform resource identifier (URI) referencing a media file,and/or a bar code.

Listing Manager Services

In accordance with various embodiments, the network-based system 110 mayprovide listing manager services for receiving, prioritizing, andprocessing updated inventory information (e.g., files including batchesof inventory items exported by inventory management systems). Forexample, the network-based system 110 may comprise a listing managersystem implemented by one or more of the communications servers 120,application servers 130, and/or databases 150 of the network-basedsystem 110. In one or more implementations, the selling servicesprovided by the network-based system 110 may include and/or involvelisting manager services for receiving, prioritizing, and processingupdated inventory information. In such implementations, the sellingserver 134 may comprise a listing manager system for providing suchservices.

It can be appreciated that while FIG. 1 shows only one selling server134 for purposes of illustration, the selling server 134 may comprisemultiple computing and/or storage devices (e.g., servers, memory,databases) which, in turn, may implement a listing manager system forperforming operations in accordance with the described embodiments. Italso can be appreciated that the listing manager system may comprise,may be implemented by, and/or may cooperate with other computing and/orstorage devices (e.g., communications servers 120, application servers130, databases 150) of the network-based system 110.

In various embodiments, the listing manager implemented by thenetwork-based system 110 may be configured to receive updated ticketinformation from a seller for multiple event listings, categorize theupdated ticket information from the seller by event, prioritize eventcategories comprising updated ticket information in accordance with aprioritization policy, and process a prioritized event categorycomprising updated ticket information for a particular event listingout-of-order with respect to one or more other event categoriescomprising previously-received updated ticket information for otherevent listings. The prioritization policy may ensure that multipleupdates for a specific event listing are processed in order according totime received by the network-based system 110. Further details of anexemplary listing manager system are described below with reference toFIGS. 2 and 3.

Buying Services

The buying server 136 implemented by one or more of the applicationservers 130 may allow a user to locate goods offered for sale via anonline marketplace provided by the network-based system 110. To findgoods for sale such as a single or multiple event tickets, a buyer mayview active event listing published by the network-based system 110.

In accordance with various embodiments, information may be presented toand/or received from information from the user via one or more userinterfaces presented on the display of a client device (e.g., PC ormobile device). The user interfaces presented to the user by aclient-side web application may comprise a search engine interface(e.g., text entry boxes, input fields, checkboxes, clickable hyperlinks,pull-down menus, etc.) for allowing the user to provide event criteriafor searching and/or filtering event listings. The user interfacespresented to the user also may comprise search results includingupcoming event listings that satisfy the event criteria.

For example, the buyer may browse active event listings by clicking andfollowing links for various event categories and subcategories such assports tickets, concert tickets, theater tickets, cities, sports, teams,artists, show type (e.g., Broadway, opera, ballet, comedy), event names,and so forth. The buyer also may search for events using a search engineinterface and/or one or more pull-down menus. For example, the buyer mayenter one or more keywords into a search engine text entry box and viewresults comprising active events that satisfy the query. In variousimplementations, the buyer may be presented with a ticket finder screencomprising a plurality of pull-down menus for allowing the buyer toquickly formulate a search by selecting a category (e.g., sports,concert, theater, etc.), a location (e.g., city), and a number oftickets from the pull-down menus.

In some embodiments, a user may search for and/or request upcoming eventinformation based on a variety of event criteria such as an event name,category, city, venue, artist, genre, team, player (e.g., startingpitcher, favorite player), theater, date range, date, number of tickets,price range, ticket attributes (e.g., zone range, zone, section range,section, row range, row, seat number range, seat number), and/orcombination thereof. Accordingly, the event criteria included in asearch query may comprise ticket attributes as well as one or moreconditions associated with the event parameters for requestinginformation for such upcoming events only when such conditions are met.

Various combinations of event criteria are possible in accordance withthe described embodiments. For example, a user may request upcomingevent information specifying combinations such as a certain number oftickets and a maximum price, a particular artist and a certain city, acertain player and a particular event venue, and so forth. A user alsomay request upcoming event information based on one or more ticketattributes. For instance, a user may request a certain number of ticketsfor an upcoming event in one or more specified zones, sections, rows,and/or or seats. Additionally, event criteria may be applied alone or incombination across one or more events. A user may request, for example,tickets in a certain row (e.g., front row) or row range (e.g., rows 1-5)within a specified zone (e.g., club infield) or section (e.g., section224) for a designated team (e.g., professional baseball team) and/or forone or more games (e.g., particular opponent, rivalry game). Theembodiments are not limited in the regard.

It can be appreciated that in some cases, an upcoming event may notsatisfy all event criteria specified by the user. For example, ticketsfor an upcoming event may be available but not within a price rangespecified by the user. Additionally, there may be no upcoming eventsthat satisfy the event criteria specified by the user when there are noavailable tickets such as when no sellers have listed tickets for anevent and/or before tickets for an event go on sale. In such cases, theclient-side web application may inform the user that there are no searchresults satisfying the search criteria and then perform a new searchwith relaxed search criteria. Alternatively or additionally, theclient-side web application may automatically relax the search criteriaand attempt another search.

Once a buyer has located and selected an event, the tickets beingoffered for sale for the event may be presented to the buyer. In variousembodiments, the user may view the details of tickets being offered forsale and the location of tickets in the event venue as described inco-pending U.S. patent application Ser. No. 11/552,782 titled “Methodand System for Illustrating Where a Ticket is Located in an EventVenue,” which was filed on Oct. 25, 2006 and is incorporated byreference in its entirety. In such embodiments, the buyer may bepresented with an interactive event venue seat map and details ofavailable tickets according to criteria specified by the buyer.

In one implementation, for example, after selecting an event the buyermay be presented with an interactive event venue seat map and an initiallisting of all event tickets for sale. The event listings may includedetails such as section, row, quantity, and price and may be sorted bythe buyer according to such details. The sections of the interactiveevent venue seat map for which tickets are available may be displayed incolor while sections having no available tickets may be displayed inwhite.

Within the interactive event venue seat map, comparable orsimilarly-located (e.g., upper level) sections having available ticketsmay be displayed in the same color while sections having availabletickets that are not comparable or similarly-located may be displayed indifferent colors. For example, the colors used in the sections maycorrespond to zones for the sections with each zone comprising severalcomparable or similarly-located sections. Along with the interactiveevent venue seat map, the buyer may be presented list comprising thedifferent zone names and the color used for each zone. The names ofzones having available tickets may be displayed in black text, while thenames of zones having no available tickets may be displayed in graytext.

When presented with the interactive event venue seat map, the buyer mayroll over a particular section causing a roll-over screen to appearindicating the quantity and price range of tickets available in thatsection. By clicking on a particular section, the event listings may befiltered to display only the event listings in the selected sectionalong with the specific details (e.g., section, row, quantity, price)for such tickets. The buyer also may zoom-in, zoom-out, drag, and/orrotate the interactive event venue seat map.

When presented with the initial listing of all event tickets for sale,the buyer may filter the initial listing by inputting criteria such asone or more price ranges (e.g., $75-$286, $286-$349, $349-$442,$442-$559, and $559 and up). Once the buyer selects a price range, theevent listings are filtered to display only the event listings in theselected price range. Additionally, the interactive event venue seat mapis modified to display sections in color for which tickets are availablein the selected price range.

Each event listing may include ticket attributes such as section, row,quantity, and price. Each listing also may include a link to viewadditional details that when clicked may display the ticket attributesalong with further ticket details (e.g., seat numbers, time remaining topurchase the tickets, seller comments, delivery options), a selectivelyenlargeable image of the event venue for reviewing the location of theseats, and an action button for initiating purchase of the tickets.

To place an order for the tickets, the buyer may provide a deliverylocation, select a method of payment (e.g., credit card), confirm thetransaction details (e.g., description of the tickets, delivery method,delivery location, payment amount, and method of payment), and thecomplete the purchase. When the buyer places the order, a confirmatione-mail is sent to the buyer, and the seller is notified of the orderrequest via e-mail and requested to confirm the availability anddelivery of the tickets. Upon receiving confirmation from the sellerthat the tickets have been sent, the buyer is notified as to whendelivery can be expected. It can be appreciated that upon the sale ofthe tickets, one or more delivery options may be available depending onthe locations of the buyer and the seller, the time remaining before theevent, and/or the form of the tickets (e.g., physical tickets,electronic tickets).

Listing Catalog Services

The listing catalog server 138 implemented by one or more of theapplication servers 130 may be arranged to receive and respond toqueries and/or to provide access to event information stored in theactive events database 154. A query to the listing catalog server 138may comprise, for example, a search query, web query, web feed request(e.g., RSS feed request, ATOM feed request), API request, HTTP request(e.g., Get, Post, etc.), a web form submission (e.g., XHTML/HTML form),and/or suitable request mechanism in accordance with the describedembodiments. In various implementations, a query may be submitted to thelisting catalog server 138 via one or more communications servers 120from one or more client devices 104, client programs 106, a third-partyserver 116, and/or a third-party application 118. Queries also may besubmitted to the listing catalog server 138 internally from otherapplication severs 130 of the network-based system 110.

In one embodiment, the listing catalog server 138 may be implemented bya distributed architecture comprising a plurality of distributedindexing modules. Each of the distributed indexing modules may providean interface for receiving queries from front-end servers such as thecommunications servers 120. The distributed indexing modules may storeand build updatable indexes against which a query can be checked toexpedite retrieval of a query result. The indexes may comprise, forexample, common keywords or search terms and event IDs linked to suchkeywords or search terms. The distributed indexing modules also maycache common query results.

The distributed indexing modules may be arranged to receive updatedindexing information brokered via a message bus from a local gatherermodule. The local gatherer, in turn, may be coupled to and collectindexing information from the active events database 154. The indexingmodules may update and/or filter the indexes based on the updatedinformation received from the local gatherer module and/or informationfrom other indexing modules.

The local gatherer module may be arranged to periodically scan itemsstored in the active events database 154 and obtain updated indexinginformation. For example, the local gatherer module may request itemsfrom the active events database 154 that have changed within a giventime period. The event information stored in the active events database154 may change frequently as new event listings for upcoming events areadded and then removed when the tickets for such event listings arepurchased. Furthermore, the active events database 154 may storerelatively static information for an event such as category (e.g.,sports, concerts, theater), as well as real-time dynamic informationsuch as current event listings and true levels of ticket inventory. Itcan be appreciated that the event information maintained by the activeevents database 154 may be extremely dynamic especially in cases whereLMS and electronic ticketing services are provided by the network-basedsystem 110.

The listing catalog server 138 may receive and respond to the querieswith event information for upcoming events that satisfy such queries.The event information may be provided locally from the listing catalogserver 138, if available (e.g., cached), and/or may be retrieved by thelisting catalog server 138 from the active events database 154. Invarious implementations, event information from the listing catalogserver 138 may be communicated via one or more communications servers120 to one or more client devices 104, client programs 106, athird-party server 116, and/or a third-party application 118. The eventinformation from the listing catalog server 138 also may be providedinternally to other application severs 130 of the network-based system110.

In accordance with various embodiments, the listing catalog server 138provides detailed ticket listing and event data, as well as information(e.g., metadata) about the classifications of that data. An event maybe, for example, a sports, concerts, theater, or exclusives event, forwhich sellers are permitted to post tickets for sale. Genre is acategory classification for classifying one or more events. Each eventmay be directly associated with one or more detailed-level genres. Forexample, an event or game of a particular team may be directlyassociated with a team tickets genre. That team tickets genre, in turn,may be classified under a more generic sport (e.g., baseball) genre.Geography (geo) is another category classification defining the locationof an event. Category classification data may comprise, for example,search dimension data and/or metadata.

A ticket listing is a batch of individual tickets that sellers may postfor sale via the network-based system 110. Ticket listings areassociated with specific events and may have different restrictions suchas the sale method (e.g. auction, fixed price, etc.) or whether theseller permits selling the constituent tickets in multiple batches oronly as a single batch (e.g. ticket listing ‘splits’ may or may not beallowed). Ticket listings also contain information about the generaltype of seat within a specific venue (e.g., row, section, seats). Ticketlistings also include the single price that each ticket within thelisting is to be sold per the preference of the seller.

The data may be organized and/or stored by the listing catalog server138 and/or stored in the active events database 154 within indexdocuments. Exemplary types of index document include genre, geography,event, ticket, and others (e.g., venue, co-brand, logistics condition).Each unique index document instance may refer, for example, to a uniqueoccurrence of a genre, geo, event, or ticket data set. Within each indexdocument are fields which provide names and values of searchableattributes (e.g., price field) which allow searching for documentinstances (e.g., the value of the price field within a certain range).

Exemplary information parameters that may be included in various typesof index document are described below in the following tables. It can beappreciated that the tables represent exemplary index document types andthat other document types may be used in some implementations. It alsocan be appreciated that the index documents may include different eventinformation parameters, additional event information parameters, orfewer information parameters than those described in the tables.

Exemplary information parameters that may be included in a genre indexdocument are described below in the following table.

Genre Index Document Fields Table Genre Document Field Details Activeindicates an active genre classification ancestorDescriptions shows anordered list of space-separated parent genre names; from the mostgeneral to the most specific category level. A search for a match on anysubset returns this query as a descendant. ancestorGenreIds shows anordered list of parent genre unique ids; from the most general to themost specific category level. A search for a match on any subset returnsthis query as a descendant. ancestorKeywords shows comma-separated listof related keywords to ancestors of this genre. A search for a match onany subset of these keywords retrieves this descendant genre in itsresult set. categorySearch- shows space-separated list of relatedkeywords to Keywords this genre. A search for a match on any subset ofthese keywords retrieves this genre in its result set. channel showsgeneral root category of site navigational flow to this sub-category.This usually corresponds to a browser tab label on the website (e.g.Sports, Concerts, Theater, Exclusives) channelid unique numeric id ofgenre document corresponding to channel field item channelUrlPath urlstring segment that site rewrites when navigating to this event genrecategory to make the HTTP Request URL more user-friendly than using idnumbers. dateLastIndexed shows the date when this document was lastadded or updated into the document index to be searchable. This datetime may be later than when the data was updated in the underlying basedatabase. deleted indicates whether this genre has since been deletedand should no longer be used for sellers to post new ticket listings.description general description of genre genreId unique identifier forgenre document genre_parent_name string corresponding to this genre'sparent description hidden This indicates that an Active Genre can beused for creating new Events; but that this Genre will not be displayedon the site. leaf Is true if this genre is the most detailed category inits classification tree. False if it is the parent of more detailedgenre categories parent_id the integer parent genre id of this genre.This is used to map the parent-child relationships among genres.season_ticket_flag This indicates whether this genre is being used as atime-search-dimension for a particular event season. DocumentId uniqueId of indexed document as qualified by the Document Type DocumentTypedocument type (e.g., genre) for results urlpath url string segment thatsite rewrites when navigating to this event genre category to make theHTTP Request URL more user-friendly than using id numbers. Correspondsto the current genre.

Exemplary information parameters that may be included in a geographyindex document are described below in the following table.

Geography Index Document Fields Table Geography Document Field DetailsActive indicates an active geo classification dateLastIndexed shows thedate when this document was last added or updated into the documentindex to be searchable. This date time may be later than when the datawas updated in the underlying base database. deleted indicates whetherthis genre has since been deleted and should no longer be used forsellers to post new ticket listings. description general description ofthis geography geoId unique numeric identifier for this geographydocument instance hidden This indicates that an event can be created foran active Geo; but that this Geo will not be displayed on the site.parent_id Unique number for parent geography id for this geography. Thisis used to map the parent-child relationships among geographies.season_ticket_flag This indicates whether this geo is being used as atime-search-dimension for a particular event season. DocumentTypedocument type (e.g., geography) for results

Exemplary information parameters that may be included in an event indexdocument are described below in the following table.

Event Index Document Fields Table Event Document Field Detailsact_primary Home Team Mascot act_secondary Away Team Mascot date_inhandDate on which the primary vendor starts selling tickets for the eventdate_confirm Date on which the seller must confirm date_on_sale Date onwhich the ticket can be sold date_last_modified Time of last change tothe event active 1 = active event 0 = inactive event allowedtoConform 1= seller allowed to confirm 0 = seller not allowed to confirmallowedtosell 1 = general public allowed to sell tickets 0 = generalpublic not allowed to sell tickets genre_parent ID of the parent genreof the event genre_grand_parent_id genreId of the parent genre of theimmediate genre_parent of this event genre_grand_parent_name name of theparent genre of the immediate genre_parent of this eventancestorGenreIds List of parent IDs, in order of hierarchy, identifyingbrowsing path to reach the node channelId ID of the top level genre inthe breadcrumb trail tied to the event geography_parent ID of the parentgeo of the venue ancestorGeoIds List of geography IDs, in order ofhierarchy, identifying browsing path to reach the geography nodeevent_date Date and time of the event (GMT) event_date_local yyyy-mm-ddof the event event_date_time Date and local time of the eventhide_event_date 1 = event date hidden 0 = event date not hiddenis_eticket_allowed 1 = e-tickets allowed 0 = e-tickets not allowedsearchKeywords searchable terms for the event DocumentType document type(e.g., event) for results venue_name Name of the venue for the eventtotalTickets Actual number of tickets listed for the event

Exemplary information parameters that may be included in a ticket indexdocument are described below in the following table.

Ticket Index Document Fields Table Ticket Document Field Detailsevent_id eventId of the event for which the tickets have been listed.end_date the date and time up to which the ticket can be sold. Thelisting becomes inactive and the ticket cannot be sold if the end dateis passed. Id the ticket listing Id used to uniquely identify thelisting ticket_medium_id medium of tickets. 1 = Paper tickets 2 = PDFtickets 3 = Barcode tickets ticket_list_type_id contains the differenttypes of listings that can be posted. A listing may be a ticket (seat)or a parking pass or a combination. 1 = Ticket plus parking pass bundled2 = Only tickets 3 = Only parking pass sale_method_id represents thetype of sale method chosen by the seller for the listing. 0 = Auctionlisting 1 = Fixed price listing 2 = Declining price listing quantitynumber of tickets originally listed by the seller for an eventquantity_remain number of individual tickets within a single ticketlisting. This will start the same as the quantity originally listed andwill be decremented as tickets are sold to reflect unsold quantity stillavailable. DocumentType document type (e.g., ticket) for resultssplit_option indicates if the ticket listing can be sold in multiplesub-batches rather than only as a single batch of tickets. 1 = ticketlisting may be sold in multiples of the ticket_split number. 0 = ticketlisting can only be sold as a single batch and not in multiplesub-batches. ticket_split When split_option = 1: Never leave a quantityof 1 ticket remaining unless ticket_split is 1 Allow any multiple ofticket_split unless it breaks the above rules Allow remainder ofticket_split multiples but only if this leaves an even split multiplemax_decay_price upper limit for the ticket price in the declining priceoption min_decay_price lower limit for the ticket price in the decliningprice option reserve_price minimum price at which the seller would bewilling to accept to sell his tickets section section of a seat within avenue row_desc row of a seat within a section of a venuebuy_it_now_price price set by the seller to close the auctionstart_price depends on the value of the sale_method field Auction,start_price = bid starting price Declining, start_price = first offeredprice and will drop to reserve_price Saled, start_price = fixed pricecurr_price current price per individual ticket system_status currentstatus of the listing (active, inactive, hidden, pending lock)showTicketKeyStr derived field based on data from other base fields. Thefirst part of this value is the type of document which in this case isalways ticket. The second part indicates if the listing is active orinactive. This string is set to a derived ACTIVE status if the ticketquantity remaining is greater than zero, if the system_status is active,and the event end_date is earlier than NOW. Otherwise the listing isconsidered INACTIVE. The final part represents event_id. Using thisfield reduces the number of separate fields to search against. Forexample, the clause of the query using this field would look like:+showTicketKeyStr:ticketACTIVE512528

The listing catalog server 138 may provide HTTP access for remoteapplications to query for the data internal to the network-based system110. The listing catalog server 138 may return document data for eachdocument satisfying the query as formatted text. A count of the numberof documents returned may be provided in the header section of theresponse. The text format of the results can be specified in the HTTPRequest or, by default, may be a proprietary XML format of thenetwork-based system 110.

In various implementations, the listing catalog server 138 may employclassification data hierarchies or metadata to classify event and ticketlistings according to independent search dimensions (e.g., Genre andGeo). Classifications form a hierarchy or tree of categories. Forexample, events may be classified into genres categories. Genres, inturn, are themselves classified into a hierarchical tree-like structure.Within a hierarchy, each event may be associated with an immediateparent genre where that parent genre is the most detailed category or isat the lowest level of the hierarchical tree. As an example, the generalbaseball tickets genre is a parent of the more specific team ticketsgenre, and this forms a genre classification hierarchy or tree. Forinstance, a genre classification hierarchy may be as follows: alltickets—sports tickets—baseball tickets—2008 MLB Tickets—2008 MLBregular season tickets—team tickets. In this hierarchy, the team ticketsgenre would be considered a leaf node of the genre dimensionclassification hierarchy.

Events also can also be classified into geographies or locationcategories. Geographies, in turn, are themselves classified into ahierarchical tree-like structure analogous to the genre hierarchystructure. Again, each event may be associated with an immediate parentgenre where that parent geography is the most detailed category or is atthe lowest level of the hierarchical tree structure.

The listing catalog server 138 may contain data types which may bequeried for details or fact data regarding posted event and ticketlistings. The fact data, in turn, may contain specific measures such asspecific occurrences of quantity and price. Each document includes anidentifier (id) field for containing a unique numeric identifier. Thisid field may be used to map relationships between multiple documents ofdifferent categories. For example, the genre parent field of an eventdocument refers to the unique genre field of a genre document.Accordingly, the one-to-many relationship among the genre parent andseveral events may be represented in this manner.

The listing catalog server 138 may be arranged to receive and respond tothe query with a response including the requested event information forthe upcoming events. In some embodiments, the response provided by thelisting catalog server 138 may include event information delivered via aweb feed or other suitable delivery mechanism. While the eventinformation may be received by the server-side web applicationimplemented by the third party 114 via a request/response mechanism, itcan be appreciated that alternatively and/or additionally, the listingcatalog server 138 may periodically push event information to theserver-side web application implemented by the third party 114 in someimplementations.

Exemplary event information parameters that may be included in theresponse from the network-based system 110 are described below in thefollowing table.

Event Information Parameter Table Event Parameter Details act_primaryHome Team Mascot act_secondary Away Team Mascot active_type 1 = activeevent 0 = inactive event allowedtosell 1 = general public allowed tosell tickets 0 = general public not allowed to sell ticketsancestorGenreIds List of parent IDs, in order of hierarchy, identifyingbrowsing path to reach the node ancestorGeoIds List of geography IDs, inorder of hierarchy, identifying browsing path to reach the geographynode canceled 1 = event has been canceled 0 = event has not beencanceled channel Name of the top level genre in the breadcrumb trailtied to the event channelId ID of the top level genre in the breadcrumbtrail tied to the event channelUrlPath URL path for the top level genrein the breadcrumb trail tied to the event channel_facet_str ID and Nameof the top level genre in the breadcrumb trail tied to the event cityCity of the event date_last_modified Time of last change to the eventdescription Name of the event eventDate_facet_str Month and year of theevent, numeric (yyyy-mm) and alpha (month, yyyy) eventGeoDescriptionName of venue event_date Date and time of the event (GMT)event_date_local yyyy-mm-dd of the event event_date_time Date and localtime of the event event_id Unique ID of the event event_time_local Localtime of the event genreUrlPath URL path for the parent genre of theevent genre_parent ID of the parent genre of the event geoUrlPath URLpath for the venue of the event geography_parent ID of the parent geo ofthe venue hide_event_date 1 = event date hidden 0 = event date nothidden id ID of the event last_chance Date and time to delist the eventused in place of the actual event date due to shipping rules maxPriceHighest ticket price for the event maxSeatsTogether Maximum number ofsuccessive seats that can be purchased together minPrice Lowest ticketprice for the event name_primary Event match-up using team mascots(e.g., Mets vs Braves) name_secondary Full name of the away team (e.g.,New York Mets) spark_event_flag Event marked as a “hot” event stateState of the event totalPostings Number of actual postings for the eventtotalTickets Actual number of tickets listed for the eventvenue_config_id Configuration of the venue for the event

It can be appreciated that, in some implementations, not all of theevent information parameters included in the table may be necessary toperform certain operations. Accordingly, when all parameters areincluded in a response, the response may be parsed to extract only thoseparameters that are needed. Alternatively, the query and/or the responsemay be configured to request and respond with only certain parameters.It also can be appreciated that different event information parametersand/or additional event information parameters than those described inthe table may be used.

In accordance with various embodiments, the listing catalog server 138may support the capabilities of the network-based system 110 toprioritize and process updated inventory information for event listingby responding to queries and providing access to, organizing, and/orstoring event information the active events database 154. Whenprioritizing and processing updated inventory information for eventlistings, the network-based system 110 and/or the listing catalog server138 may provide various domain-based capabilities (e.g., APIcapabilities). Exemplary inventory domain capabilities may include,without limitation, defining inventory entities,creating/updating/deleting inventory, getting inventory for a seller foran event, getting an inventory skeleton (e.g., tree of events for whichinventory is available) for a seller, re-parenting inventory to a newevent, deactivating inventory, and/or event granularity and en masseoperations. Exemplary inventory/catalog domain capabilities may include,without limitation, finding matching events, creating placeholder events(e.g., for partial matches), scrubbing inventory for venue, and/oradding an alias to an event if a placeholder event maps directly to anexisting event. Exemplary inventory/seller domain capabilities mayinclude, without limitation, creating/updating/retrieving a listingmanager file profile. f the query using this field would look like:+showTicketKeyStr:ticketACTIVE512528 Dynamic Content Management Services

The dynamic content management server 140 implemented by one or more ofthe application servers 130 may be arranged to provide a user withrelevant and/or related dynamic content customized according to aparticular context of the user. The dynamic event information maycomprise, for example, event information that changes as new eventlistings for upcoming events are added and as event listings are removedwhen the tickets for such event listings are purchased and real-timeevent-specific information such as current event listings, price ranges,and true levels of ticket inventory. Relevant or related dynamic contentmay comprise, for example, dynamic content customized according to thelocation of the user such as location-based advertising content (e.g.,banner ads), relevant and/or related categories and subcategories (e.g.,links for local sports teams, artists performing in the location,theater shows playing in the location), a list of event names and datesfor upcoming events in the location arranged by category, and/or othertype of dynamic featured content that changes according to the locationof the user.

In some implementations, the appearance of a user interface displayed tothe user may be customized or branded with dynamic content based on thelocation of the user and/or event criteria specified by the user. Forexample, a web page or web client may comprise a comprise a header,skin, or other designated area that dynamically displays differentgraphics (e.g., pictures, logos, backgrounds, etc.), advertisements,news, and/or other featured content received from the network-basedsystem 110 according to the location and/or event criteria of the user.

In various embodiments, the dynamic content management server 140 may bestructured, arranged, and/or configured to bind dynamic information to aparticular node and/or combination of nodes defining the context of theuser. Exemplary nodes may include, for example, geography nodes (e.g.,event cities), category nodes (e.g., sports, concerts, theater), sportsnodes (e.g., baseball, football, basketball), sports subcategory nodes(e.g., professional, college), music genre nodes (e.g., jazz, rock,alternative), theater subcategory nodes (e.g., musical, comedy), ticketsubcategory nodes (e.g., regular season, playoff, bowl), conferencenodes, team nodes, artist nodes, theater show nodes, venue nodes, eventnodes, and so forth. It can be appreciated such nodes may be arranged(e.g., hierarchically) and/or in other ways in accordance with thedescribed embodiments.

The dynamic content management server 140 may be configured bind dynamiccontent such as relevant and/or related categories and subcategories,event listings for upcoming events, promotional or advertising content,UI graphics, and/or various other types of customized content to a nodeor combination of nodes. When navigating a web site provided by thenetwork-based system 110, for example, the user may be presented withlinks for selecting from among various locations, categories, and/orsubcategories and for viewing content associated with such selections.When the user makes a particular selection, the context of the user maybe defined by one or more nodes associated with such selection, and theuser may be presented with dynamic content customized to the context ofthe user.

In various embodiments, the dynamic content management server 140 mayimplement a front-end query tool and presentation layer to query thelisting catalog server 138 according to the context of the user. Inresponse to the query, the dynamic content management server 140 mayreceive dynamic content (e.g., XML content) from the listing catalogserver 138 and provide the dynamic content to one or more dynamiccontent modules embedded in a web page presented to the user.Accordingly, the content associated with event listings may change basedon the context of the user, configurable parameters, and/or availableinventory.

In one example, a user selects a particular city, and the dynamiccontent management server 140 has bound dynamic content to a geographynode associated with the particular city. Upon selection of theparticular city by the user, the context of the user may be defined atleast in part by the geography node of the selected city, and the usermay be presented with the dynamic content that is bound to the geographynode. In this case, the user may be presented with a web page includingdynamic content customized for the particular city such as graphics(e.g., pictures, background) and advertising content (e.g., banner ads)for the particular city, relevant and/or related categories andsubcategories (e.g., links for local sports teams, artists performing inconcert in the city, theater shows playing in the city), a list of eventnames and dates for upcoming events in the city arranged by category,and/or other type of dynamic content that changes according to the cityselected by the user.

In another example, a user selects a particular football team, and thedynamic content management server 140 has bound dynamic content to ateam node associated with the particular football team. Upon selectionof the team by the user, the context of the user may be defined at leastin part by the team node, and the user may be presented with the dynamiccontent that is bound to the team node. In this case, the user may bepresented with a web page including dynamic content customized for theparticular team. For example, the web page presented to the user may bedynamically branded with graphics (e.g., pictures, background),advertising content (e.g., banner ads), and/or news associated with theparticular team. The user also may be presented with event listings forupcoming games for the team as well as relevant and/or relatedcategories and subcategories (e.g., links for road games, playoff games)for the team. In this implementation, the context of the user may bedefined by one or more other nodes in a hierarchical path to the teamnode such as a category node (e.g., sports), sports nodes (e.g.,football), sports subcategory node (e.g., professional), and ticketsubcategory node (e.g., regular season). As such, the user may bepresented with dynamic content bound to one or more of such nodes suchas links to other professional football teams for which regular seasontickets are available.

It can be appreciated that the embodiments are not limited to theforegoing examples and that dynamic content may be bound to a particularnodes and/or a combination of nodes for customizing that contentdisplayed to a user based on the context of the user. Accordingly, thedynamic content management server 140 may be used to create dynamiccontent campaigns including a various types of static and dynamiccontent and to bind such campaigns to nodes or groups of nodes thatdefine a context of the user. It also can be appreciated that a nodeand/or combination of nodes can be detected as a user selects one morelinks and/or in other ways such as when a query is submitted (e.g., textentry, selection of checkboxes, selection from a pull-down menu), asearch result is returned, or in any other way in accordance with thedescribed embodiments.

Payment Services

The payment server 142 implemented by one or more of the applicationservers 130 may be arranged to effectuate and/or manage payments betweenbuyers and sellers and to post and track financial transactions forusers of the network-based system 110. Transaction information for pastand pending transactions may be stored by the network-based system 110in the transaction database 156. The payment server 142 also may providedispute resolution mechanisms to handle payment disputes arising betweentransacting parties and/or fraud prevention mechanisms to preventfraudulent transaction, unauthorized use of financial instruments,non-delivery of goods, abuse of personal information, and so forth.While the payment server 142 is shown in FIG. 1 as forming part of thenetworked-based system 110, it will be appreciated that the paymentserver 142 may form part of a third-party payment system that isseparate and distinct from the network-based system 110 in alternativeembodiments.

In various implementations, the payment server 142 may account for atransfer of funds and/or financial value by debiting the a source offunds and/or financial value linked to the subscriber account of thebuyer and crediting a source of funds and/or financial value linked tothe subscriber account of the seller. For example, the network-basedsystem may securely communicate with one or more financial institutionssuch as a bank or credit card company over one or more networks 108 andarrange the transfer of funds and/or financial value from the buyer tothe seller. It can be appreciated that while certain settlementmechanisms may be described for purposes of illustration, theembodiments are not limited in this regard, and a variety of settlementnetworks and modalities may be used in accordance with the describedembodiments.

In one embodiment, after the buyer reviews and confirms an order, theaccount (e.g., credit card) of the buyer is verified, and the saleamount (e.g., ticket price plus delivery cost) is authorized. The selleris notified of the proposed purchase by e-mail or other notificationmechanism and requested to confirm that the tickets are still availableand that the transaction can be completed.

Upon receiving confirmation from the seller, the account (e.g., creditcard) of the buyer is charged. Funds from the account of the buyer maybe electronically transferred into a merchant account associated withthe network-based system 110, and a transaction fee may be deducted. Theremaining proceeds are then directed to the seller by issuing a paymentin accordance with the payment method selected by the seller such as viacheck, deposit to a third-party payment services account (e.g., PayPal™account), Season Ticket Account, and/or other type of source capable ofreceiving funds and/or financial value, and/or donation to a third-partysuch as a non-profit organization or entity.

It can be appreciated that the network-based system 110 may provide a“double blind” complete ticket-sale transaction without interactionbetween buyer and seller. Namely, the network-based system 110 mayfacilitate an entire ticket-sale transaction without requiring anyinteraction between the seller and the buyer. The network-based system110 controls and/or facilitates the entire sale and purchase process andserves as an intermediary between the buyer and seller effectivelyisolating the participation of the seller in the transaction from theparticipation of the buyer in the transaction. Accordingly, the identityof one transacting party can remain concealed from the other.

Notification Services

The notification server 144 implemented by one or more of theapplication servers 130 may be arranged to generate and send varioustypes of notifications to users of the network-based system 110. Thenotification server 144 may communicate with users over one or moretypes of networks 108 (e.g., the Internet, a WAN, a WWAN, a WLAN, amobile telephone network, a landline telephone network, a VoIP network,etc.) via interfaces provided the communications servers 120 such as theweb server 122, API server 124, and/or messaging server 126. It can beappreciated that, in some implementations, notifications may beforwarded to users via an intermediary such as an Internet ServiceProvider (ISP), online service provider (OSP), web-based e-mail serviceprovider, message aggregator (e.g., SMS aggregator), mobile transactionnetwork entity, and so forth.

The notifications may comprise messages delivered to users via e-mail,IM, SMS, MMS, video message, telephone call as well as messagesdelivered to the subscriber account of the user. In some cases, thenotifications may provide the user with information related to variousonline marketplace transactions. For example, notifications may be sentto sellers for indicating the status of event listings, informing theseller of offers (e.g., auction bids) for event listings or sales ofsimilar tickets and allowing the user to modify the prices of eventlistings, notifying the seller of placed orders and requestingconfirmation of the availability of tickets for such orders, providingdelivery instructions and requesting confirmation of delivery, trackingshipped orders, providing the status of payments, and so forth.Notifications may be sent to buyers for tracking ticket purchasetransactions (e.g., active bids, auctions lost) for event listings andallowing the buyer to modify offers, confirming an order and delivery,tracking shipped orders, providing pick-up instructions and requestingconfirmation of receipt, downloading and print electronic tickets, andso forth.

In various embodiments, the user may subscribe to receive customizedalert notifications for upcoming events as described in co-pending U.S.patent application Ser. No. 12/262,468 titled “System and Methods forUpcoming Event Notification and Mobile Purchasing,” which was filed onOct. 31, 2008 and is incorporated by reference in its entirety. In suchembodiments, the notification server 144 may be arranged to generate andsend an alert notification comprising a text message including relevantstatic or dynamic event information as well as an embedded hyperlink.The hyperlink may comprise a hyperlinked telephone number for allowingthe user to place a telephone call to an agent of the network-basedsystem 110 for transacting a mobile purchase. Alternatively oradditionally, the hyperlink may comprise a URL or URI for navigating tothe network-based system 110 for transacting the mobile purchase.

It can be appreciated that in some cases, an upcoming event may notsatisfy all event criteria specified by the user. In someimplementations, when there are no upcoming events that satisfy all theevent criteria specified by the user, the user may select to receivealert notifications for one or more upcoming events conditioned on thecomplete satisfaction of the event criteria. In such implementations,the network-based system 110 may allow the user to select to receive analert notification whenever an upcoming event that substantially and/orcompletely satisfies the search criteria is listed. For example, theuser may select to receive “on sale” alert notifications when ticketsthat satisfy one or more preferences of the user become available, Thenetwork-based system 110 also may provide the user with variouscapabilities (e.g., preference settings and options) to allow the userto receive “on sale” alert notifications for preferred tickets and toallow the user to automatically and/or optionally purchase suchpreferred tickets.

In accordance with various embodiments, a seller such as high-volumeseller (e.g., ticket broker) may communicate updated inventoryinformation to the network-based system 110 which, in turn, may beprioritized and processed. In such embodiments, the stages involved inreceiving, prioritizing, and processing updated inventory informationmay be monitored by the network-based system 110. For example, theupdating of inventory information according to one or more receivedinventory files (e.g., full file jobs, delta jobs, consolidator jobs)may be broken into a receiving stage, a prioritizing stage, and aprocessing stage. Each stage may be monitored, and event logs may begenerated and reported when a file arrives, when file data isprioritized, and when prioritized file data is processed. Service levelagreements (SLAs) may be established so that a network operations center(NOC) may log, track, and generated appropriate alerts in accordancewith SLA contracts. All failure modes and corresponding stages may berecorded when errors occur. In the event that a failure condition isencountered at any stage, notifications may be provided to thesubscriber account and/or a computing device of the seller (e.g.,broker) as well as one or more customer service agents (e.g., largeseller support team, event management team) of the network-based system110. It can be appreciated that decoupling processing stages from eachother provides more robustness and visibility into where problems mayoccur.

Delivery Services

The delivery server 146 implemented by one or more of the applicationservers 130 may arrange the delivery of goods from the seller to thebuyer. For the delivery of time-sensitive goods such as a single ormultiple event tickets, the network-based system 110 may determine andpresent delivery options that ensure that an event ticket is deliveredto the buyer before an event and the costs associated with such deliveryoptions.

In various embodiments, the network-based system 110 may coordinate thedelivery of event tickets as described in co-pending U.S. patentapplication Ser. No. 09/867,171 titled “System and Method for ProvidingLogistics for a Sale of Goods,” which was filed on Sep. 27, 2001 and isincorporated by reference in its entirety. In such embodiments, thenetwork-based system 110 may automatically arrange and/or facilitate thelogistics for the delivery of event tickets from the seller to thebuyer.

In one implementation, for example, when the buyer places an order,available delivery options are presented to the buyer that ensure thatthe event tickets can be delivered before the event either to the buyeror to a pick-up location (e.g., event venue will call or an office ofthe network-based system 110) in proximity to the buyer. Thenetwork-based system 110 may determine all available delivery optionsbased on the form of the tickets (e.g., physical tickets, electronictickets), the time remaining before the event, the location of thegoods, the location of the buyer, pick-up locations in proximity to thebuyer, and/or the capabilities one or more couriers (e.g., air/landcouriers, express couriers, local couriers or “runners”) that canexecute the delivery within the time remaining before the event.

When a physical ticket is to be delivered, the network-based system 110may determine and present shipping options to the buyer. The buyer mayprovide a delivery or pick-up location, and the network-based system 110may automatically determine couriers capable of ensuring delivery andpresent a list identifying the couriers, the available shipping methods(e.g., two day, one day, overnight, same day) for each courier, and theassociated cost of each shipping method.

When a courier and shipping method is selected by the buyer, the sellermay be notified and presented with a printable shipping label for thecourier and logistics for providing the tickets to the courier. Forexample, the network-based system 110 may automatically determine theclosest courier facility in proximity to the seller and may allow andarrange for the courier to retrieve the tickets. In such cases, thenetwork-based system 110 may communicate relevant information (e.g.,seller address, delivery address, pick-up day and time frame) to thecourier in order to coordinate ticket retrieval. If the courier cannotservice any of the selected locations at any of the selected times, thenetwork-based system 110 may require the seller to drop off the ticketsat the nearest courier facility. The seller also may select to drop offthe tickets at the nearest courier facility. If the seller selects or isrequired to drop off the tickets, the buyer may be provided with thelocation of the courier facility, driving or walking directions to thecourier facility, and/or a map showing the courier facility.

Upon confirmation by the seller that the tickets have been sent orpicked up, the network-based system 110 may communicate deliverytracking information to the buyer and/or seller. The network-basedsystem 110 may notify the buyer of the delivery location and expectedtime and date of delivery. If the delivery location is at a pick-uplocation such as the event venue will call or an office associated withthe network-based system 110, the buyer may be provided with the pick-uplocation, driving or walking directions to the pick-up location, and/ora map showing the pick-up location.

To ensure delivery to the buyer before an event, a last sale time may beassociated with an event listing. In some cases, for example, the lastsale time for an event listing may be three business days before theevent to provide sufficient transit time to ensure completion ofdelivery. In such cases, the event listing will expire at the last saletime.

Last Minute Services

It can be appreciated that both sellers and buyers may desire the lastsale time to be as close to the event start time as possible in order tomaximize the opportunity to make a sale and the opportunity to witnessan event. Accordingly, the network-based system 110 may provide sellersand buyers with various last minute services (LMS) for maintaining anevent listing and the ability to sell and purchase listed tickets rightup to the start of the event.

In one implementation, for example, the network-based system 110 mayallow tickets to be sold on consignment and may maintain an eventlisting until the start of the event. When a seller requires delivery ofphysical tickets for an upcoming event, the seller may select to sellthe tickets using LMS provided by the network-based system 110. Theseller may request LMS and provide the network-based system 110 withcontact information (e.g., name, address, telephone number, e-mailaddress), ticket information (e.g., event name, event venue, ticketevent dates, closest city to the event), and authorization to releasethe tickets.

In response to the LMS request, the seller may be contacted by an agentof the network-based system 110 via telephone or other contact methodand provided with additional selling information. Depending on the timeremaining before the event, the seller may be instructed to ship orphysically deliver the tickets to an LMS center associated with thenetwork-based system 110. Typically, the location of the LMS center willbe in close proximity to the event venue. The seller also may select tophysically deliver the tickets to the LMS center. When physical deliveryof the ticket to the LMS center is required or selected, the seller maybe provided with the location of the LMS center, driving or walkingdirections to the LMS center, and/or a map showing the LMS center.

Once the tickets are delivered to the LMS center, the event listing maybe maintained until the start of the event and the subsequent deliveryof the tickets to a buyer is handled by the network-based system 110.For example, the LMS center and/or the network-based system 110 mayhandle the responsibility of shipping the tickets to the buyer,delivering the tickets to the event venue will call, and/or the keepingthe tickets at the LMS center until pick-up by the buyer. It can beappreciated that the LMS provided by the network-based system 110 mayfacilitate delivery and allow the network-based system 110 to defer thelast sale time until the start of the event.

In some embodiments, an LMS center may employ an inventory managementand/or accounting system capable of providing real-time inventoryupdates to the network-based system 110. In other embodiments, the LMScenter may provide a batch of updated inventory to the network-basedsystem 110 which, in turn, may be prioritized and/or processed asdescribed herein.

Electronic Ticketing Services

In various embodiments, the network-based system 110 may provideelectronic ticketing services for allowing a buyer to purchase one ormore electronic tickets that can be used at the event venue. It can beappreciated that providing such electronic ticketing services may allowthe network-based system 110 to defer the last sale time until the startof the event.

When the user selects an upcoming event from event listings published bythe network-based system 110, a web page may be presented to the userthat includes event information for the selected upcoming event such asthe name of the event, the date and time of the event, the event venue,available ticket listings including ticket attributes (e.g., section,row, quantity, price), and so forth. In some cases, a purchaser of eventtickets may provide the event information to the network-based system110 in order to list the tickets for sale on a secondary market. Inother cases, the venue, event promoter, or other type of ticket issuermay provide the network-based system 110 with event details such asevent description, event venue, event date and time, artist, and soforth. In response, the network-based system 110 may manage the event,enable the venue to sell tickets for the event, manage the generationand distribution of electronic tickets, and facilitate the use ofelectronic tickets for access control to the venue. For example, thenetwork-based system 110 may create an event listing, generateelectronic tickets, publish available tickets for sale, and coordinatethe sale of the electronic tickets.

In various embodiments, a web page presented to a user may comprise theevent information along with a link to purchase electronic ticketsand/or a link to view additional details. By clicking the link topurchase electronic tickets, the user may initiate a purchase of one ormore electronic tickets. By clicking the link to view additionaldetails, a subsequent web page may be displayed including ticketattributes along with further ticket details (e.g., seat numbers, timeremaining to purchase the tickets, seller comments, delivery options), aselectively enlargeable image of the event venue for reviewing thelocation of the seats, and an action button for initiating purchase ofthe tickets. In some cases, one or more web pages may include a link toview delivery options such as a location of, driving or walkingdirections to, and/or a map showing a pick-up location.

To effectuate an electronic ticket purchase, the user may be prompted toenter account information such as a unique username or e-mail addressand a password. Upon receiving the required account information, theuser is authenticated with the network-based system 110 and may initiatean electronic ticket purchase. After authentication, the network-basedsystem 110 may transact the purchase using a source of financial valuelinked to the subscriber account of the user or may request the user tosupply payment information (e.g., credit card account, PayPal™ account,etc.) for the transaction.

In various embodiments, a user may purchase electronic tickets and/orsave electronic ticket information using a web client such as a webbrowser, web browser toolbar, and/or a desktop or mobile widget. Forexample, a user may save an electronic ticket and/or a hyperlink to afile associated with the electronic ticket in a subscriber account, inthe web browser toolbar, and/or within a desktop or mobile widget. Theuser also may display information for and differentiate among purchasedelectronic tickets on a client device (e.g., PC or mobile device) viathe web client.

The buyer may purchase one or more electronic tickets using a creditcard or other source of funds or financial value linked to thesubscriber account of the buyer. In one or more embodiments, thenetwork-based system 110 may provide variable distribution and accesscontrol for purchased electronic tickers. For example, the network-basedsystem 110 may provide the buyer with various delivery options forreceiving and/or delivering the purchased electronic tickets.

The network-based system 110 may allow the buyer to have the electronictickets delivered to an e-mail address associated with the buyer. Thebuyer may access the e-mail account, display the electronic tickets, andprint out paper copies of the electronic tickets. Each of the papercopies of the electronic tickets may include a bar code which can bescanned at the event venue to allow access.

Alternatively or additionally, the buyer may instruct the network-basedsystem 110 to send an electronic ticket to a mobile device (e.g., mobilephone or PDA) associated with the buyer. For example, the buyer mayreceive the electronic ticket at the mobile device and display a barcode of the electronic ticket on a screen of the mobile device which maybe scanned at the event venue to grant access. In some usage scenarios,the buyer may receive an SMS message sent to a mobile device thatincludes a link to a web page to render a ticket. In other usagescenarios, the buyer may receive an MMS message sent to a mobile devicethat includes an image of the ticket. When the buyer chooses delivery toa mobile device, the buyer also may receive the ticket via e-mail as abackup in case the buyer wants to print out a paper copy to bring to oruse at the event venue. The buyer may receive a text message at the timeof ticket purchase and, if the tickets are purchased more than apredetermined time before the event (e.g., two days before the event), areminder text message just before (e.g., one day prior to) the event.

In various embodiments, when the buyer purchases electronic ticketsusing a credit card, the buyer may access the venue by swiping thecredit card used to make the purchase at the event venue. Alternativelyor additionally, the buyer may use a driver's license to validate theticket at the event venue. In some implementations, only the buyer mayuse the credit card used to make the purchase or a driver's license as ameans of entry at the event venue. It can be appreciated that in suchimplementations, the buyer may validate his/her ticket at the venue aswell as validate other purchased tickets for other people who arepresent with the buyer at the time of entry into the event venue.

The network-based system 110 also may provide the buyer with variousdelivery options for splitting the distribution of a single order ofmultiple electronic tickets among one or more recipients in addition toand/or other than the buyer. In some cases, for example, a buyer maypurchase multiple electronic tickets (e.g., block of four electronictickets) at once in a single order. In such cases, the buyer may choosefrom the provided options for variably distributing one or more of thepurchased electronic tickets and/or the underlying rights associatedwith one or more of the purchased electronic tickets to different endrecipients using different delivery mechanisms.

In various implementations, when a buyer purchases more than one ticket,the buyer may choose to have the tickets delivered directly to one ormore other recipients for use at the event venue. For example, whenmultiple tickets are purchased in one order, the buyer can decide howindividual tickets will be delivered electronically (e.g., e-mail, SMS,MMS, etc.) to another person. Upon delivery, each ticket may be used bythe recipient independently of the buyer arriving at the event so thatthe entire party does not need to be present to enter the event venue.In such implementations, the buyer may be presented with deliveryoptions as described in co-pending U.S. patent application Ser. No.12/325,789 titled “System and Methods for Variable Distribution andAccess Control for Purchased Event Tickets,” which was filed on Dec. 1,2008 and is incorporated by reference in its entirety.

In various implementations, the network-based system 110 may communicatethe access rights to an electronic ticketing system at the event venueto associate the electronic ticket with the buyer and/or one or morerecipients. Access control at the event venue may be done by a scannerthat will read a bar code contained on the ticket sent as describedabove. In some cases, the buyer may access the venue by swiping thecredit card used to make the purchase at the event venue or a driver'slicense. The buyer also may validate other purchased tickets for otherpeople who are present with the buyer at the time of entry into theevent venue. Each ticket delivered to a recipient may be usedindependently of the buyer arriving at the event so that buyer does notneed to be present for the recipient to enter the event venue.

As the purchaser, the buyer may retain ownership and control of thedistribution of the tickets. The network-based system 110 allows thepurchased tickets to be easily delivered to different end recipients andmay be configured to distribute the purchased electronic tickets and/orthe underlying rights associated with electronic tickets differentlybased on ownership. In various embodiments, the tickets and/or theunderlying rights associated with the tickets may be distributed todifferent end recipients by the network-based system 110 withoutaffecting ownership, without relisting the tickets, and/or withoutrequiring the recipients to purchase the tickets.

It can be appreciated that when ownership and control of the tickets isretained by the original purchaser, the ability of a recipient to resellthe tickets may be restricted. In some cases, however, the purchaser maychoose to transfer complete ownership of an electronic ticket and/or theunderlying rights associated with the electronic ticket to a recipient.In various embodiments, the network-based system 110 may be configuredto support and broker the transfer of electronic tickets from thepurchaser to multiple end recipients as well as from a recipient toanother individual (e.g., buyer or other recipient). For example, thenetwork-based system 110 may allow a recipient to list a received ticketfor sale and may automatically handle the assignment of rights to asubsequent buyer when the ticket is purchased.

In cases where ownership and the underlying rights of an electronicticket are transferred from the purchaser, the network-based system 110may communicate access rights to an electronic ticketing system at theevent venue to associate the electronic ticket with a differentindividual (e.g., recipient or subsequent buyer). In some embodiments,the network-based system 110 may instruct the ticketing system toactivate new electronic tickets with new bar codes and to deactivate theoriginal electronic tickets and original bar codes of the purchaser. Thenew electronic tickets can be delivered by the network-based system 110and/or the electronic ticketing system for use by the recipient orsubsequent buyer.

Alternatively or additionally, the network-based system 110 may instructthe ticketing system to associate new identification and/orauthorization information (e.g., credit card, swipe card, password, pincode) with the electronic tickets and to deactivate identificationand/or authorization information of the purchaser from the electronictickets. Upon providing the required identification and/or authorizationinformation to the electronic ticketing system, to a kiosk at the eventvenue, and/or to the network-based system 110, the recipient orsubsequent buyer can use the electronic ticket to access the eventvenue.

As described above, the network-based system 110 may provide listingmanager services for receiving, prioritizing, and processing updatedinventory information. In various usage scenarios, the listing managerservices may be provided to large-volume sellers (e.g., ticket brokers)in conjunction with selling services and/or other services provided bythe network-based system 110.

FIG. 2 illustrates an exemplary listing manager system 200 forprioritizing and processing updated inventory information for eventlistings in accordance with various embodiments. The listing managersystem 200 may be configured, for example, to receive updated ticketinventory and to prioritize and process workloads to ensure thatpublished ticket listings reflect updated inventory available for sale,especially during critical time periods associated with an event. Withreference to FIG. 1, the listing manager system 200 may be implementedby one or more of the communications servers 120, application servers130, and/or databases 150 of the network-based system 110 which, inturn, may provide online marketplace (e.g., secondary ticket market) andticket fulfillment services. The embodiments, however, are not limitedto this context.

In various implementations, the listing manager system 200 may beconfigured to receive updated ticket information from a seller formultiple event listings, categorize (e.g., bucket) the updated ticketinformation from the seller by event, prioritize event categories (e.g.,event buckets) comprising updated ticket information in accordance witha prioritization policy, and process a prioritized event categorycomprising updated ticket information for a particular event listingout-of-order with respect to one or more other event categoriescomprising previously-received updated ticket information for otherevent listings. The prioritization policy may ensure that multipleupdates for a specific event listing are processed in order according totime received by the listing manager system 200.

As shown, in FIG. 2, the listing manager system 200 may comprisefunctional subsystems including a file accepting subsystem 210 to accepta file comprising updated inventory information, an event bucketcreating subsystem 220 to create event buckets by bucketing the file byevent and to enqueue the event buckets into a priority queue 230, and anevent bucket processing subsystem 240 to process an event bucket fromthe priority queue 230.

The accepting subsystem 210 may be configured to receive updatedinventory information that is uploaded to one or more large seller (LS)inboxes such as LS inbox 205. In various implementations, the LS inboxesmay comprise FTP inboxes associated with high-volume or large sellerssuch as ticket brokers. Each LS inbox may correspond, for example, to aparticular seller (e.g., ticket broker) and may be associated with aparticular LS identifier (LS ID) of the seller.

As described above, in some usage scenarios a seller may manage andupdate inventory on a POS and/or inventory management system and thencommunicate a batch of updated inventory information to thenetwork-based system 110. The batch of updated inventory may comprise,for example, a file that is exported from the POS and/or inventorymanagement system of the seller to a particular inbox (e.g., LS inbox205) associated with the seller. In some cases, the file may comprise afull file job listing of all inventory of the seller, a delta joblisting changes to inventory information previously sent or uploaded,and/or a consolidator job listing inventory information associated withmultiple different sellers which, in turn, may include full file jobsand/or delta jobs for different ticket brokers.

The accepting subsystem 210 may be configured to monitor the LS inboxesfor files uploaded by sellers. In some embodiments, the acceptingsubsystem 210 may be configured to monitor particular LS inboxes forcertain types of files (e.g., full update, delta, consolidated, etc).For example, the file type(s) for a particular LS inbox may be stored ina profile linked to the LS ID of the seller. In some cases, differentfile types may require different queuing and/or processing and may bedistinguished (e.g., tagged) by the accepting subsystem 210.

In various implementations, the accepting subsystem 210 may employmultiple servers for scanning and/or polling the LS inboxes in parallelso that multiple polling jobs may run concurrently. Accordingly, theaccepting subsystem 210 may be configured to avoid resource starvation.A typically starvation situation is when files are taken in order, and aseller submits a very large file which unfairly consumes resources. Inthis situation, other files of other sellers which may include importantupdates to inventory may be deprived of processing until the resourcesbeing consumed by the large file are released. It can be appreciatedthat the use of multiple servers to perform parallel polling is designedto take fairness into consideration when allocating resources and toavoid starvation situations.

Upon detecting uploaded files in the LS inboxes, the accepting subsystem210 may move the files from the LS inboxes into the appropriate archivaltable. In various embodiments, an archive file is created as a raw copyof the file to log an event when a file arrives and keep a record ofwhen updated inventory information was received. In some cases, archivefiles may be used for dispute resolution with brokers. The acceptingsubsystem 210 may then enqueue the file for further processing by theevent bucket creating subsystem 220. In various implementations, theaccepting subsystem 210 may enqueue the file using the job-schedulingfacilities (e.g., gen3 quartz-based facilities) of the network-basedsystem 110 and/or may notify the event bucket creating subsystem 220that a new file is ready for processing.

The event bucket creating subsystem 220 may request and/or receive anunprocessed file containing inventory uploaded to an FTP area (e.g., LSinboxes of external partners) to create event buckets. In variousimplementations, the files may be normalized, for example, by columnorder using a column-name scheme. The event bucket creating subsystem220 may group a file in memory, for example, by event using raw eventinformation in the file. For example, the event bucket creatingsubsystem 220 may retrieve rows grouped by raw event information in thefile.

In one or more embodiments, the event bucket creating subsystem 220 mayperform event scrubbing to ensure that the events listed in the filecorrespond to events recognized by the network-based system 110. In suchembodiments, the event bucket creating subsystem 220 may convert rawevents into events recognized by the network-based system 110, forexample, by performing an event lookup (e.g., LCS-based search). In theevent that an event listed in the file does not convert (e.g., less-than100% confidence matches) and/or no suitable corresponding eventrecognized by the network-based system 110 is found, the event bucketcreating subsystem 220 may perform event scrubbing which creates atemporary placeholder event to hold the inventory. The event bucketcreating subsystem 220 may enqueue an event mapping request so thatsubsequently an agent (e.g., event management team) of the network-basedsystem may re-parent the inventory and/or add an alias to an event if aplaceholder event maps directly to an existing event. In some cases, theevent scrubbing may require an e-mail to be sent to the sellerrequesting further information regarding the event so that an event canbe created.

The event bucket creating subsystem 220 may then create event bucketsand bucket the inventory information in the file by event. In variousembodiments, multiple servers may be working concurrently on files tocreate event buckets. An event may be logged when all event buckets arecreated from a file. The event bucket creating subsystem 220 may thenupdate the file record and enqueue the event buckets into the priorityqueue 230. In various implementations, file processing by the eventbucket creating subsystem 220 is atomic to ensure that a given file willbe processed exactly once and the event buckets will be inserted intothe priority queue 230 exactly once.

It can be appreciated that while the updated inventory information maybe categorized or bucketed at the event level, the embodiments are notlimited in this regard. In some implementations, for example, updatedinventory information may be categorized or bucketed according tosection (e.g., floor section), row (e.g., front row), or other suitableticket level criteria. Accordingly, the prioritization of categories orbuckets comprising updated inventory information may be based on variousticket level criteria in some embodiments.

The event bucket processing subsystem 240 may process an event bucketfrom the priority queue 230 in accordance with a prioritization policy.In various implementations, the event buckets may be placed into and/orretrieved from the priority queue 230 based on the prioritizationpolicy. In accordance with the prioritization policy, a prioritizedevent bucket comprising updated ticket information for a particularevent listing may be processed out-of-order with respect to one or moreother event buckets comprising previously-received updated ticketinformation for other event listings. It can be appreciated that whileFIG. 2 shows only one priority queue 230 for purposes of illustration,the listing manager system 200 may comprise multiple priority queues.For example, different priority queues may be associated with differentpriority levels, and event buckets may be placed into and/or retrievedfrom such queues based on prioritization of the queues.

In accordance with various embodiments, the event buckets comprisingupdated ticket inventory may be prioritized based on one or morefactors. In general, prioritization of the event buckets may be designedto ensure that most valuable and/or important inventory information isupdated as soon as possible and/or out-of-order with respect to lessvaluable and/or less important inventory information. In someembodiments, for example, prioritization may be based on when an eventis to occur such as the time remaining before the event date. Becausetickets for the event will have no value after the event date, theprioritization policy may ensure that event buckets containing updatedinventory information for an event with an event date occurring within acertain threshold time period (e.g., 48 hours) are placed into and/orretrieved from the priority queue 230 ahead of other event bucketscontaining updated inventory information for later-occurring events.

In some embodiments, prioritization may be based on the on-sale date fortickets to an event. Since the days including and/or immediatelyfollowing the on-sale date for tickets to an event generally are timeperiods of high activity for buying and selling, the prioritizationpolicy may ensure that event buckets containing updated inventoryinformation for an event with an on-sale date that is recent (e.g.,within 48 hours) or impending (e.g., within 24 hours) or are placed intoand/or retrieved from the priority queue 230 ahead of other eventbuckets when the timing associated with events of the other eventbuckets is less critical. For example, the timing for an event may beless critical during the time period between the days including and/orimmediately following the on-sale date and the days immediatelypreceding and/or including the event date which is generally a time oflower activity for ticket sales. Because tickets for the event will haveno value after the event date, the prioritization policy still mayensure that event buckets containing updated inventory information foran event with an impending event date are placed into and/or retrievedfrom the priority queue 230 ahead of event buckets containing updatedinventory information for an event with a recent or impending on-saledate.

Additionally or alternatively, prioritization may be based on whetherthe updated inventory information is deleting inventory, addinginventory, and/or merely updating ticket details. Because the accuracyof the remaining inventory for an event may be more important relativeto whether additional tickets for an event are available, theprioritization policy may ensure that event buckets containing updatedinventory information that deletes inventory are placed into and/orretrieved from the priority queue 230 ahead of other event bucketscontaining updated inventory information that adds inventory and/orupdates ticket details.

In some embodiments, prioritization also may be based on a prioritylevel (e.g., platinum, gold, silver, etc.) associated with a seller. Insuch embodiments, event buckets containing updated inventory informationfor certain sellers may be placed into and/or retrieved from thepriority queue 230 ahead of inventory updates from other sellersaccording to criteria such as number of listings, volume of sales,commission generated, comments (e.g., positive or negative feedback),and so forth. In some cases, a seller may pay a premium (e.g., fixedfee, additional commission percentage) to obtain a particular prioritylevel. In such cases, event buckets containing updated inventoryinformation for certain sellers may be placed into and/or retrieved fromthe priority queue 230 ahead of inventory updates for other sellersaccording to such premiums.

In implementations where the seller pays a premium for obtaining apriority level, the prioritization policy may ensure that inventoryupdates from a priority seller are taken ahead of inventory updates froma non-priority or lower-priority seller in situations where updatedinventory information is being submitted for the same impending event.In some cases, the prioritization policy even may ensure that inventoryupdates from a priority seller are taken ahead of inventory updates fromnon-priority or lower-priority sellers regardless of the timing of anevent. For example, the inventory updates from a priority seller mayplaced into and/or retrieved from the event bucket priority queue 230ahead of inventory updates from non-priority or lower-priority sellerseven if the inventory updates from the non-priority or lower-prioritysellers are for events having impending event dates and/or recenton-sale dates.

Upon receiving an event bucket from the priority queue 240, the eventbucket processing subsystem 240 may process the event bucket byretrieving inventory information by seller and event. In variousimplementations, the event bucket processing subsystem 240 may beconfigured to ensure in-order processing for a given seller. Forexample, to avoid out-of-order updates of inventory, files broken up byevent are processed according to a file arrival/creation time asdetermined by the network-based system 110. In the event that multipleevent buckets for a given seller are updating the same event, the eventbuckets for the given seller files are processed in order by filearrival time.

In one or more embodiments, the event bucket processing subsystem 240may be configured to ensure in-order processing for event listings.Although various listings may be processed out-of-order given theprioritization policy, the event bucket processing subsystem 240 shallensure that updates for a specific listing are applied in order by filearrival time. Accordingly, when a particular seller makes multipleupdates to available ticket inventory or ticket pricing for a specificlisting, the updates are processed in order of arrival to ensure thatthe specific listing is published with accurate and up-to-dateinformation. For example, if a seller mistakenly submits a lower priceand then submits an updated higher price for a listing, the updatedhigher price is processed after the low price to ensure that the listingreflects the most recent price update.

The event bucket processing subsystem 240 may then compute differencesbetween the inventory information of the seller included in the eventbucket against the inventory associated with the seller that iscurrently listed for a given event. In one or more embodiments, theevent bucket processing subsystem 240 may perform venue scrubbing sothat the data can be conditioned as soon as possible and reported backto the seller (e.g., ticket broker) or agent (e.g., large seller accountmanager or venue management team) of the network-based system 110 toreport how well data is being scrubbed. Venue scrubbing may comprise,for example, matching updated inventory information for a venue againstrecognized venues, creating a placeholder for an unmatched venue, andsubmitting a mapping request for the unmatched venue.

The event bucket processing subsystem 240 may update the inventory ofthe seller listed by the network-based system 110. The event bucketprocessing subsystem 240 may then update the file and the bucket recordto note when an event bucket has been processed. In variousimplementations, the event bucket processing subsystem 240 may generateand/or maintain a stable ticket ID in the event that a ticket ID is notprovided in the original input file. The event bucket processingsubsystem 240 generally will not consolidate listings that are in thesame row.

FIG. 3 illustrates a logic flow 300 including operations performed by acomputer for prioritizing and processing updated inventory informationfor event listings in accordance with various embodiments. The logicflow 300 may be performed by various systems and/or devices and may beimplemented as hardware, software, firmware, and/or any combinationthereof, as desired for a given set of design parameters or performanceconstraints. For example, the logic flow 300 may be implemented by alogic device (e.g., computer and/or processor) and/or logic (e.g.,computer executable program instructions) to be executed by a logicdevice.

As shown, the logic flow 300 may comprise logic and/or operations toaccept a file (block 310) which, in turn, may include logic and/oroperations to receive a file (e.g., consolidator jobs, delta jobs, fullfile jobs) (block 312), archive a file (block 314), and enqueue a file(block 316).

The logic flow 300 may comprise logic and/or operations to bucket a fileby event (block 320) which, in turn, may include logic and/or operationsto get an unprocessed file (block 322) and retrieve rows grouped by rawevent (block 324). As shown, bucketing a file by event (block 320) mayinclude logic and/or operations to perform an event scrub (block 326)which, in turn, comprises logic and/or operations to perform an eventlookup (block 328) and enqueue an event mapping request (block 330).Bucketing a file by event (block 320) also may comprise logic and/oroperations to create event buckets (block 332), update a file record(block 334), and enqueue event buckets (block 336).

The logic flow 300 may comprise logic and/or operations to store eventbuckets in a priority queue (block 338) and to process an event bucket(block 340). In various embodiments, an event bucket may be processed inaccordance with a prioritization policy. For example, an event bucketmay be placed into and/or retrieved from a priority queue based on theprioritization policy. In accordance with the prioritization policy, aprioritized event bucket comprising updated ticket information for aparticular event listing may be processed out-of-order with respect toone or more other event buckets comprising previously-received updatedticket information for other event listings. The prioritization policymay ensure that multiple updates for a specific event listing areprocessed in order according to time received.

As shown, processing an event bucket (block 340) may comprise logicand/or operations to retrieve inventory by seller and event (block 342),compute differences (block 344), perform a venue scrub (block 346),update inventory (block 348), and update a file/bucket record (block350).

It can be appreciated that while the logic flow 300 may illustrate acertain sequence of logic and/or steps, other sequences of logic and/orsteps may also be performed in accordance with the describedembodiments. Moreover, some individual steps of the logic flow 300 mayinclude multiple sub-steps that may be performed in various sequences asappropriate to the individual step. Furthermore, additional steps may beadded or some steps may be removed depending on the particularimplementation.

In various embodiments, one or more operations of the logic flow 300 maycomprise, or be implemented as, executable computer programinstructions. The executable computer program instructions may beimplemented by software, a software module, an application, a program, asubroutine, instructions, an instruction set, computing code, words,values, symbols or combination thereof. The executable computer programinstructions may include any suitable type of code, such as source code,compiled code, interpreted code, executable code, static code, dynamiccode, and the like. The executable computer program instructions may beimplemented according to a predefined computer language, manner orsyntax, for instructing a computer to perform a certain function. Theexecutable computer program instructions may be implemented using anysuitable programming language in accordance with the describedembodiments.

In various embodiments, one or more operations of the logic flow 300 maycomprise, or be implemented as, executable computer program instructionsstored in an article of manufacture and/or computer-readable storagemedium. The article and/or computer-readable storage medium may storeexecutable computer program instructions that, when executed by acomputer, cause the computer to perform methods and/or operations inaccordance with the described embodiments. The article and/orcomputer-readable storage medium may be implemented by various systemsand/or devices in accordance with the described embodiments.

The article and/or computer-readable storage medium may comprise one ormore types of computer-readable storage media capable of storing data,including volatile memory or, non-volatile memory, removable ornon-removable memory, erasable or non-erasable memory, writeable orre-writeable memory, and so forth. Examples of computer-readable storagemedia may include, without limitation, random-access memory (RAM),dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM(SDRAM), static RAM (SRAM), read-only memory (ROM), programmable ROM(PROM), erasable programmable ROM (EPROM), electrically erasableprogrammable ROM (EEPROM), flash memory (e.g., NOR or NAND flashmemory), content addressable memory (CAM), polymer memory (e.g.,ferroelectric polymer memory), phase-change memory, ovonic memory,ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS)memory, magnetic or optical cards, or any other suitable type ofcomputer-readable storage media in accordance with the describedembodiments.

Although some embodiments may be illustrated and described as comprisingexemplary functional components or modules performing variousoperations, it can be appreciated that such components or modules may beimplemented by one or more hardware components, software components,firmware components, and/or combination thereof.

Unless specifically stated otherwise, it may be appreciated that termssuch as “processing,” “computing,” “calculating,” “determining,” or thelike, refer to the action and/or processes of a computer or computingsystem, or similar electronic computing device, that manipulates and/ortransforms data represented as physical quantities (e.g., electronic)within registers and/or memories into other data similarly representedas physical quantities within the memories, registers or other suchinformation storage, transmission or display devices.

It is worthy to note that some embodiments may be described using theexpression “coupled” and “connected” along with their derivatives. Theseterms are not intended as synonyms for each other. For example, someembodiments may be described using the terms “connected” and/or“coupled” to indicate that two or more elements are in direct physicalor electrical contact with each other. The term “coupled,” however, alsomay mean that two or more elements are not in direct contact with eachother, but yet still co-operate or interact with each other. Withrespect to software elements, for example, the term “coupled” may referto interfaces, message interfaces, API, exchanging messages, and soforth.

While certain features of the embodiments have been illustrated asdescribed above, many modifications, substitutions, changes andequivalents will now occur to those skilled in the art. It is thereforeto be understood that the appended claims are intended to cover all suchmodifications and changes as fall within the true spirit of theembodiments.

What is claimed is:
 1. A system comprising: a memory storing ticketinformation for a plurality of sellers; and a hardware processor incommunication with the memory and operable for: receiving updated ticketinformation from a plurality of sellers; processing the updated ticketinformation from one of the plurality of sellers in conjunction withanother one of the plurality of sellers; prioritizing the updated ticketinformation for an event based on a time relative to an on-sale date fortickets to the event or relative to a date for the event; and updatingpublished ticket listings for the event based on the prioritized updatedticket information.
 2. The system of claim 1, wherein processing theupdated ticket information from another one of the plurality of sellersis performed by a second hardware processor.
 3. The system of claim 1,wherein the receiving is through files uploaded by sellers into inboxes.4. The system of claim 3, wherein the processing comprises scanning theinboxes in parallel using multiple processors.
 5. The system of claim 1,wherein the processing comprises performing a lookup in the system foran event associated the updated ticket information.
 6. The system ofclaim 5, wherein the hardware processor is further operable for sendingan email to the one of the plurality of sellers when the event is notrecognized by the system.
 7. The system of claim 6, wherein the emailcomprises a request for additional information about the event.
 8. Thesystem of claim 1, wherein the hardware processor is further operablefor categorizing updated ticket information into event-specific buckets.9. The system of claim 8, wherein the event-specific buckets areprioritized based on the time relative to the on-sale date for ticketsto the event or relative to the date for the event.
 10. The system ofclaim 1, wherein the prioritizing is based on a time remaining beforethe date of the event.
 11. A computer-implemented method comprising:receiving updated ticket information from a plurality of sellers;processing, by a server of a service provider, the updated ticketinformation from one of the plurality of sellers in conjunction withanother one of the plurality of sellers; prioritizing the updated ticketinformation for an event based on a time relative to an on-sale date fortickets to the event or relative to a date for the event; and updatingpublished ticket listings for the event based on the prioritized updatedticket information.
 12. The method of claim 11, wherein the prioritizingis further based on a type of information being updated for the event.13. The method of claim 11, wherein the prioritizing is further based onwhether the updated ticket information deletes ticket inventory,increases ticket inventory, or updates ticket details for the event. 14.The method of claim 13, wherein a higher priority is placed on theupdated ticket information that deletes or increase ticket inventoryversus the updated ticket information that updates ticket details. 15.The method of claim 11, wherein the prioritizing is further based on apriority level of the seller.
 16. The method of claim 11, whereinprocessing the updated ticket information from another one of theplurality of sellers is performed by a second server of the serviceprovider.
 17. The method of claim 11, further comprising matchingupdated ticket inventory information for an event against eventsrecognized by the service provider; creating a placeholder for anunmatched event; and submitting a mapping request for the unmatchedevent.
 18. A non-transitory computer-readable storage medium comprisingexecutable computer program instructions executable by a computer systemto cause the computer system to: receive updated ticket information froma plurality of sellers; process the updated ticket information from oneof the plurality of sellers in conjunction with another one of theplurality of sellers; prioritize the updated ticket information for anevent based on a time relative to an on-sale date for tickets to theevent or relative to a date for the event; and update published ticketlistings for the event based on the prioritized updated ticketinformation.
 19. The non-transitory computer-readable storage medium ofclaim 18, wherein the updated ticket information is further prioritizedbased on whether updated ticket inventory information is deleting ticketinventory, adding ticket inventory, or updating ticket details.
 20. Thenon-transitory computer-readable storage medium of claim 18, wherein theupdated ticket information for the event is placed in a prioritizedevent bucket.